Postgres MCP servers compared: giving your AI agent a database

TL;DR. A Postgres MCP server gives an AI agent (Claude Code, Cursor, ChatGPT, Codex) tools to read a database's schema, run SQL and, on some servers, run migrations. As of August 2026 the main choices are the hosted servers from database vendors (the Supabase MCP server, Neon's), open-source SQL MCP servers you run yourself against any Postgres (Postgres MCP Pro, DBHub, Google's MCP Toolbox for Databases), and the cloud vendors' own servers. The deciding questions are where the database lives and how much write access you can tolerate. On Hatchable there is nothing to pick: every project has a private Postgres the connected agent already reaches over MCP.

What a database MCP server lets an agent do

A database MCP server is a small service that exposes tools such as list_tables, describe_table and execute_sql over the Model Context Protocol. Once it is registered in the client, the agent can answer "how many orders shipped on Friday?" by inspecting the schema, writing the query, running it and reading the rows back, without you pasting anything. Richer servers add more: migrations (Neon's prepares schema changes on a temporary branch, Supabase's applies them through a dedicated tool), EXPLAIN plans and index suggestions (Postgres MCP Pro's speciality), log queries, and branching. Generic SQL MCP servers do the same for MySQL, SQL Server and SQLite, usually with a smaller tool set.

In practice this is what makes an agent useful on a real project rather than a toy. It can check that a migration did what it said, debug a failing endpoint by looking at actual rows, and build features that depend on data that already exists.

The risks: write access and production data

The same execute_sql tool that runs SELECT runs DROP TABLE. Three risks come up repeatedly:

• Unreviewed writes. An agent that can write will eventually write something you did not mean. Every server in this comparison ships some form of read-only mode; use it for anything that is not a dev database, and keep the client's per-tool approval prompt on for writes.
• Production data in the context window. Rows the agent reads go to the model provider. That is fine for a side project and a compliance question for customer data. Scope the server to one project or database, and prefer a dev branch or copy.
• Prompt injection through data. Text stored in a table can contain instructions. A read-only role and a narrow tool set limit what a tricked agent can do.

The vendors say the same thing in their own docs: Supabase recommends development projects, read-only mode and project scoping; Neon tells you to review and authorise every action the LLM requests. Treat those as defaults, not suggestions.

Postgres and SQL MCP servers compared, August 2026

Supabase MCP server

Supabase hosts a remote server at https://mcp.supabase.com/mcp. You sign in through the browser (dynamic client registration, no personal access token to paste), and URL parameters shape the access: read_only=true runs every query as a read-only Postgres user, and project_ref pins the server to one project and switches account-level tools off. Tool groups cover the database, debugging and logs, edge functions, docs, storage (off by default) and experimental branching. It is the obvious choice if your data is already in Supabase; the trade-off is that the scope is your Supabase account, so scoping and read-only mode are doing real security work. A local mode runs through the Supabase CLI.

Neon MCP server

Neon hosts its server at https://mcp.neon.tech/mcp with OAuth sign-in or an API key in the Authorization header. The tools span projects, branches, schema, SQL, Neon Auth and docs; the notable one is the migration workflow, which applies a schema change on a temporary branch so you can inspect it before it touches the main branch. ?readonly=true disables writes, ?projectId confines it to one project, and ?category turns on only the groups you want. Neon's docs note the older SSE endpoint is deprecated and stops working on or after October 1, 2026, and the local stdio package is deprecated in favour of the hosted server.

Postgres MCP Pro (crystaldba/postgres-mcp)

The open-source, MIT-licensed Python server you run yourself against any Postgres you can reach. Two access modes: unrestricted (full read/write, for development) and restricted (read-only transactions with resource limits, for anything shared). Beyond execute_sql and schema tools it does what a DBA would: explain_query, index recommendations across a workload, and a database health check. As of August 2026 its README lists stdio and SSE transports, installable via Docker, pipx or uv. You provision the host, the connection string and the network path.

The archived reference server

The original @modelcontextprotocol/server-postgres from Anthropic's reference repo still shows up in tutorials. It now lives in the project's archived servers repository, which is marked as no longer maintained, with no security updates or bug fixes. Do not start a new setup on it.

Generic SQL MCP servers

DBHub (from Bytebase) is a single open-source server for PostgreSQL, MySQL, MariaDB, SQL Server and SQLite. It deliberately loads only two tools by default (execute_sql and search_objects) to save context, and has a read-only mode, row limits, query timeouts and SSH tunnelling; it runs via Docker or npx. MCP Toolbox for Databases is Google's open-source server for Cloud SQL, AlloyDB, BigQuery, Spanner and self-managed Postgres and MySQL, handling authentication and connection pooling for you. Azure's MCP Server has tools for Azure Database for PostgreSQL (list databases and tables, read schema, run read queries) with Entra or password auth. If your query is "mcp sql server" in the Microsoft sense, DBHub and Toolbox both cover SQL Server.

Comparison table

General characterisations based on public information as of August 2026; check each vendor for current details.

The Hatchable shape: a database the agent already has

Hatchable starts from the other end. Every project gets its own private PostgreSQL database the moment it is created, with real SQL and real migrations, on every plan including free. The agent you connected at https://hatchable.com/mcp (Claude, Claude Code, Cursor, Codex, ChatGPT, Gemini) reaches that database over the same MCP connection it uses to write files and deploy: get_schema to inspect it, execute_sql for queries and one-off data fixes, and migration files in the project for schema changes, which apply in order at deploy. There is no connection string to paste, no second server to register, and no account-wide scope to worry about, because a project's database is reachable only from that project. If you want to look at the rows yourself, the console shows each table as a spreadsheet-style view with editing and export.

The trade-off is equally plain: this is the database for apps built on Hatchable. It is not a way to point an agent at an existing RDS instance or a legacy warehouse; for that, use one of the servers above. What it replaces is the whole "provision a database, then provision an MCP server for it" sequence for new projects. The step-by-step shows the flow from a blank project to an agent running queries, and the database feature page lists what is included. The free plan covers unlimited private projects and one published app, no card.

How to choose

If your data is already in Supabase or Neon, use their hosted server, switch read-only on for anything real, and scope it to one project. If the database is somewhere else (RDS, a VPS, on-premises), run Postgres MCP Pro for a Postgres-only setup with tuning tools, or DBHub if you also have MySQL or SQL Server in the mix, and put it behind an auth layer before any cloud client sees it. If you are starting a new app with an agent and the database does not exist yet, the simplest answer is a platform where the database and the agent's access to it arrive together. For how the agent gets connected in the first place, see connect Claude Code or connect Cursor.