---
title: "Tiger MCP vs. Postgres MCP Server"
description: "Compare Tiger MCP to generic, Neon, and Supabase Postgres MCP servers. See which fits your setup, plus a real MCP security incident to know about. "
section: "Alternatives"
---

> **TimescaleDB is now Tiger Data.**

## What's the best MCP server for PostgreSQL? 

The short answer? There is no single best Postgres MCP server, only the best fit for the job. Use a generic, open-source server to explore a database you already run. Use Neon or Supabase's own server to manage that platform end to end. Use [<u>Tiger MCP</u>](https://www.tigerdata.com/docs/reference/tiger-cloud/tiger-mcp) to manage a Postgres or TimescaleDB service on Tiger Cloud with schema-aware advice built in.

One disclosure up front: Tiger Data builds Tiger MCP, so we have a stake in this comparison. We've tried to write the rest of this page the way we'd want a comparison written: state what each server actually does, name where it falls short, let the differences speak for themselves, and then let you decide which is best for your workload requirements. 

## What is Tiger MCP?

Tiger MCP is the Model Context Protocol server built into the [<u>Tiger CLI</u>](https://www.tigerdata.com/docs/reference/tiger-cloud/tiger-cli) binary. It gives an AI agent typed tools to manage Tiger Cloud services (create, fork, resize, view logs) and run SQL against them, with read-only mode and per-role access limits available by default. It also ships built-in advisory skills for Postgres and TimescaleDB: schema design, hypertable candidate detection, and continuous aggregate guidance–allbacked by documentation search.

Tiger MCP installs as part of the Tiger CLI, not as a separate package. It shares the CLI's login and permissions, so there's no second credential to manage or second tool to keep in sync. See the [<u>full CLI and MCP overview</u>](https://www.tigerdata.com/docs/learn/tiger-cli-mcp), including how they compare to the REST API, for the complete picture.

Tiger Data's own documentation draws a useful distinction between Tiger MCP and Tiger CLI: an agent working through Tiger MCP is non-deterministic by design, which makes it well-suited for database exploration, schema design, reasoning, and configuration. Tiger CLI, run directly or scripted, is for precise, repeatable execution. That's a difference that’s important to note when considering what kind of tool to use, not a feature count: one executes, the other also reasons about what to execute. It's [<u>why MCP tools are built to understand intent, not just forward API calls</u>](https://www.tigerdata.com/blog/big-shift-mcp-why-ai-guides-will-replace-api-wrappers).

## The three kinds of Postgres MCP servers

Most developer discussions about Postgres MCP servers treat them as interchangeable: SQL over stdio, more or less the same regardless of which one you pick. That assumption breaks down once you look at what these servers actually do. In reality, there are three meaningfully different categories when it comes to Postgres MCP servers:

### Bucket 1: Generic, open-source, connection-string-only servers

This bucket covers MCP servers that connect to a Postgres database you already have running and execute SQL against it. They don't manage any infrastructure.

1. Anthropic published its reference Postgres MCP server, (@modelcontextprotocol/server-postgres), early in MCP's life. Anthropic archived the project in May 2025, marking it "not ready for production use." The package remains publicly installable from npm and Docker Hub today, and some teams are likely still running it.
2. Postgres MCP Pro (crystaldba/postgres-mcp) is generally considered one of the more fully-featured servers in this category. It tends to offer configurable read and write access, health checks, and index-tuning analysis based on query plans, and is one of the more widely adopted open-source options in this space. Crystal DBA, the company that developed it, was reportedly acquired in 2026, which is not uncommon in the industry. However, the server remains available. 
3. pgEdge's Postgres MCP server tends to be the broadest self-hosted option, generally supporting local and HTTP modes, authentication, and a web UI on top of standard Postgres. Even so, it's still fundamentally a tool you point at a database you already have running.

A handful of smaller, indie MCP servers also exist on GitHub, with varying schema introspection, generally thinner safety controls, and no service management.

What every server in this bucket shares: none of them manage the underlying database service. They assume you already have a running Postgres instance and a connection string.

### Bucket 2: Other vendors' platform-specific MCP servers

This is the bucket that gets flattened into bucket 1 most often even though it shouldn't. Neon and Supabase both publish MCP servers that go well beyond running SQL, but only within their own hosted platforms.

Neon's MCP server generally supports project and branch creation, documentation search, and a two-step migration workflow. That workflow separates preparing a change from committing it, and everything is scoped to Neon's own serverless Postgres platform. As of 2026, Neon connects agents through a hosted remote server with OAuth authentication rather than the local, stdio-based setup it started with.

Supabase's MCP server goes even further, managing infrastructure (projects, database, authentication, storage, edge functions), workflows (branch-based development and deployment, type generation, log retrieval), and access control (dedicated read-only role)—all scoped to Supabase-hosted projects.

Neither is a thin SQL wrapper. Their limitation relative to Tiger MCP is scope, not capability: each is built for one vendor's platform, and neither includes Postgres or TimescaleDB-specific advisory skills like hypertable design or continuous aggregate guidance. This is something to consider if you’re running a TimescaleDB instance. 

### Bucket 3: Tiger MCP

Tiger MCP combines what the other two buckets do separately: service management (create, fork, resize, view logs), SQL execution, safety controls (read-only mode, per-role access limits), and Postgres/TimescaleDB advisory skills, all installed as part of one CLI binary.

Scope matters here too. Tiger MCP works against Tiger Cloud services. It doesn't manage arbitrary third-party Postgres instances the way a generic connection-string server might reach any database you point it at.

## Feature comparison table

| **Server** | **Service management** | **SQL execution** | **Read-only / role-based controls** | **Postgres/TimescaleDB advisory skills** | **Platform scope** |
| --- | --- | --- | --- | --- | --- |
| Anthropic reference server (archived) | None | Yes | Read-only mode present, enforcement gap disclosed (see below) | None | Any Postgres connection string |
| Postgres MCP Pro | None | Yes | Configurable read/write access | None | Any Postgres connection string |
| pgEdge Postgres MCP | None | Yes | Read-only controls | None | Any Postgres connection string |
| Neon MCP | Neon projects and branches only | Yes | Read-only role available | None | Neon platform only |
| Supabase MCP | Full Supabase backend (projects, auth, storage, edge functions) | Yes | Dedicated read-only role | None | Supabase platform only |
| Tiger MCP | Tiger Cloud services (create, fork, resize, logs) | Yes | Read-only mode, per-role access limits | Yes (schema design, hypertable detection, continuous aggregate guidance, docs search) | Tiger Cloud only |

## Is "read-only mode" actually safe?

Read-only mode sounds like a guarantee. However, it’s only as strong as its enforcement, and each MCP Server’s enforcement can have gaps even in a widely installed implementation.

Datadog Security Labs documented a real, disclosed vulnerability in Anthropic's archived reference Postgres MCP server. The server wrapped queries in a read-only transaction, but it also accepted semicolon-delimited batches of statements. That combination created an opening: a crafted input could include a COMMIT statement partway through a batch, ending the read-only transaction early. Everything after the COMMIT then ran with full privileges, outside the guarantee the transaction was supposed to provide. At the time of disclosure, the package had roughly 20,000 weekly npm downloads.

The lesson here is about implementation, not the MCP itself. "Read-only" is a claim about how a server is built, not something you get for free by advertising it. A maintained, actively patched server that treats read-only enforcement as a security boundary carries a meaningfully different risk profile than one untouched since before it was archived.

It's not an isolated case, either. Multiple current vendor write-ups on MCP security independently flag the same open, category-wide issues for generic MCP servers: unscoped database access, credential exposure through chat history, and missing row- or column-level filtering. Tiger Data's own engineers have written about why [<u>MCP security is hard to get right</u>](https://www.tigerdata.com/blog/three-tigerdata-engineers-told-us-the-truth-about-mcp-security-is-its-achilles-heel), and that framing applies directly here.

Tiger MCP's specific controls are read-only mode and per-role access limits. Read-only mode disables every mutating service tool (service creation, forking, starting, stopping, resizing, password updates) and puts database sessions into Tiger Cloud's own immutable read-only mode–so writes and schema changes are rejected regardless of what the agent tries to run. Per-role limits let you connect an agent as a database role scoped to exactly the access it needs, enforced by the database itself rather than the MCP server's own logic. Teams that want extra isolation can point an agent at a fork or a read replica, keeping exploratory work off production entirely. See [<u>best practices for AI agents</u>](https://www.tigerdata.com/docs/build/tiger-cli-mcp/agent-best-practices) for specifics.

## What Tiger MCP doesn't fix

No MCP server, including Tiger MCP, completely guarantees that an agent writes efficient SQL. Foundation models commonly generate queries that miss available indexes or scan more data than necessary. That's an inherent model behavior, not something any particular server implementation causes or fully controls.

Tiger MCP's advisory skills help here: hypertable and indexing guidance can steer an agent toward a better schema and query shapes before the problem shows up in production. But that's help, not a guarantee. Pairing an agent with query-plan visibility and human review still matters, no matter which MCP server sits underneath it.

## Decision criteria

**Choose a generic, open-source MCP server if:** you already run Postgres somewhere else, want to experiment locally, and are comfortable auditing the server's safety controls yourself before pointing it at anything you care about.

**Choose Neon MCP or Supabase MCP if:** you're already building on that specific platform and want an agent that can manage your project end to end within it.

**Choose Tiger MCP if:** you're running, or plan to run, Postgres or TimescaleDB on Tiger Cloud and want one tool that lets an agent manage the service, query the data, and get both hypertable-aware and continuous-aggregate-aware advice (with read-only mode and role limits available by default).

One honest caveat: if your team wants a database-agnostic tool that works identically across many hosting providers, none of the platform-specific options, including Tiger MCP, are the right fit. A generic server is the more honest answer in that case.

## Migrating to Tiger MCP

Most teams arrive at this decision from one of three starting points.

1. If you're using a generic, open-source MCP server against a self-hosted or RDS Postgres instance, moving to Tiger MCP mainly changes how you connect and authenticate;instead of a raw connection string, you use the same login as Tiger CLI. The SQL itself, and most of your existing prompts, carry over unchanged.
2. If you're using Neon MCP or Supabase MCP and considering a move to Tiger Cloud, the shift is similar: connection and auth change, but the Postgres behavior your queries depend on does not.
3. If you don't have an MCP setup yet, there's no migration, just installation and configuration.

The setup steps live in the [<u>quickstart for connecting Tiger MCP to an AI agent</u>](https://www.tigerdata.com/docs/get-started/quickstart/mcp-cli) and the [<u>Tiger CLI and MCP cookbook</u>](https://www.tigerdata.com/docs/build/tiger-cli-mcp/cookbook), which cover configuration for specific coding assistants in more depth than this blog needs to.

## Getting started with Tiger MCP

Tiger MCP installs as part of Tiger CLI. Once the CLI is installed, `tiger mcp install` configures it for a specific AI coding assistant, including Claude Code, Cursor, and VS Code, by writing the right entry into that assistant's own configuration. For the full walkthrough, see the [<u>Tiger CLI and MCP quickstart</u>](https://www.tigerdata.com/docs/get-started/quickstart/mcp-cli). Once it's connected, [<u>free Postgres MCP prompt templates</u>](https://www.tigerdata.com/blog/free-postgres-mcp-prompt-templates) are a fast way to see what an agent can do against a real schema.

## Get started with Tiger Data MCP Server

If after reading this blog and exploring our documentation you’ve decided that Tiger Data MCP Server is the correct fit for your use case, you can get started in two ways. If you have an account already, sign-in and install the [<u>CLI/MCP Server</u>](https://console.cloud.timescale.com/projects/cli-mcp/cli). If you don’t have an account, [<u>sign up</u>](https://console.cloud.tigerdata.com/signup) and then install the CLI/MCP Server.