Best MCP servers for databases in 2026: an honest field guide.
Five shapes of database MCP server. What each is good for, where each breaks.
I built one of these for QueryDeck. Then I read the code of about twenty others. This is the field guide I wish I had when I started.
By Leonidas Jeremy, founder of QueryDeck. About 10 min read.
There are five shapes of database MCP server in the wild: run_sql wrappers, read-only run_sql wrappers, cloud vendor servers, ORM-backed RPC servers, and project-aware database client servers. Most public “Postgres MCP” results on GitHub are in the first two categories. The one you actually want for production work is in the last category — and there are fewer than five worth pointing at real data.
The run_sql wrappers
crystaldba/postgres-mcp, modelcontextprotocol/postgres example, several npm packages.
A single MCP tool that takes arbitrary SQL and proxies it to the database driver. Fast to ship, easy to read.
Zero learning curve. Works with any SQL the database accepts. Useful for learning MCP itself or sandbox exploration.
All safety on the model. The model can DROP, DELETE, or read across schemas with no friction. Schema is reverse-engineered from list_tables every conversation, so the model burns tokens guessing column names.
Verdict: Fine for a personal sandbox. Do not point it at anything you cannot afford to lose.
Read-only run_sql wrappers
Most npm "safe" Postgres MCP packages from 2025, hosted wrappers on cursor.directory.
Same shape as above, but the server refuses any non-SELECT. Often built as a thin proxy.
Solves the write problem at the protocol level. You cannot accidentally DROP or DELETE through the LLM.
Model still has unbounded read scope across the whole database. No schema context, no per-connection tagging, no audit log of what the model actually read.
Verdict: Safer floor for shared dev environments. Still no defense against the model leaking cross-schema data.
Cloud vendor MCP servers
Google Cloud SQL MCP toolbox, Azure Database MCP, AWS RDS Data API plus MCP.
MCP servers shipped by cloud providers, wired to their IAM and managed databases. Reads, writes, and schema introspection.
IAM-native. Audit logs in the cloud console. Plays well with managed database backups. Often free with the platform.
Locked to the platform. Limited or no project-awareness (no ORM schema parsing). Tool surfaces are designed for general SQL, not app-developer workflows.
Verdict: Right answer for enterprise multi-tenant or compliance-heavy environments. Wrong tool for a solo dev with a Drizzle schema.
ORM-backed RPC servers
Generated-from-Prisma MCP wrappers, a handful of Drizzle-aware experiments.
Generate one tool per model in your ORM. The tool surface mirrors the schema.
Excellent schema context. The model knows the User table has these fields with these types. Reads feel tight.
Usually locked to one ORM. Writes are often allow-all or block-all, no per-call gating. Hard to use across stacks (Prisma + Postgres + MongoDB? Pick one).
Verdict: Strong for read-heavy AI agents inside one stack. Weak for a database client that wants to work for everyone.
Project-aware database client MCP (the QueryDeck shape)
QueryDeck (this site), and a few experimental tools built on top of database GUIs.
Narrow typed tools (list_tables, describe_table, run_select, count_where, explain_plan, ...), ORM schema lifted into the tool descriptions when the project has one, writes gated behind Touch ID and a UI confirm modal, per-connection scope.
Schema context the model can use without burning tokens. Writes that genuinely require human approval. Per-connection scope, environment tagging built in. Works across Drizzle, Prisma, TypeORM, Django, ActiveRecord, Eloquent today.
Heaviest to build. Requires the underlying tooling to actually parse your project, not just take a connection string. Not free — QueryDeck is $79 once.
Verdict: What I built because I want to leave the MCP server running while I sleep.
Narrow tools, not one big SQL hatch
Look for list_tables, describe_table, get_row, run_select, count_where, explain_plan, list_indexes — separate tools, separate auditable calls. A single run_sql tool collapses all safety onto the model.
Project / schema context
Does the server lift your Drizzle, Prisma, or TypeORM schema into the tool descriptions? If yes, the model knows your column shapes before the first query. If no, the model guesses every conversation.
Writes gated with a hardware factor
INSERT, UPDATE, DELETE, DDL should require a separate tool, a human-readable diff, and a hardware factor (Touch ID, YubiKey). Not a config flag the model can flip.
Per-connection scope and environment tagging
One MCP server instance per database connection, scoped to that connection's schema. Production connections light up red across the UI and inject a banner into every read response.
What is a database MCP server?+
An MCP (Model Context Protocol) server is a local or remote process that exposes a database to LLM clients (Claude Code, Cursor, Claude Desktop) as a set of typed tools. Instead of the model writing SQL into a black box, MCP gives it structured tool calls like list_tables, describe_table, run_select. The MCP standard was published by Anthropic in late 2024 and adoption accelerated through 2025-2026 as IDE assistants standardized on it.
Why are there so many Postgres MCP servers?+
Because the minimum viable version is a five-line wrapper around a database driver. Anyone who has ever used psycopg2 can ship a Postgres MCP server in an afternoon. The result is a fragmented ecosystem where most servers expose the same single tool (run_sql) and the differentiation lives in safety, schema awareness, and scope — properties that are easy to add, but easy to forget.
Are run_sql-only MCP servers safe in production?+
No, not as built. The single-tool run_sql pattern collapses all safety onto the model. If Claude misreads your intent and generates a DELETE without a WHERE, the server runs it. DataDog Security Labs documented an SQL injection case in a popular Postgres MCP server in 2025. The fix is structural: narrow tools, write-gating, per-connection scope. See the deeper write-up on this site.
Which database MCP server should I use for Postgres in 2026?+
Depends on the use case. For a personal sandbox: any of the run_sql wrappers (crystaldba/postgres-mcp, the official MCP example servers, npm packages). For a project where you want schema context and write safety: a project-aware client that builds the MCP on top of its existing tooling (QueryDeck is the example I built). For enterprise multi-tenant: a cloud vendor server tied to your IAM (Google Cloud SQL MCP, Azure Database MCP).
Can one MCP server talk to multiple databases?+
Two patterns: (1) one server, one connection per spawn — the QueryDeck approach. The model literally cannot see the wrong database. (2) one server, many connections in config — most cloud vendor servers. The model can pick a connection by name on each call. The first is harder to misuse. The second is more flexible. Pick the trade-off that matches how careful you need to be.
Postgres MCP server for Claude Code + Cursor
The 5-line MCP config, the tool surface, and four example flows from real Cursor conversations.
See the setup →Why most database MCP servers are wrong
The longer write-up of the structural argument: three failure modes I ran into, four properties the right shape needs.
Read the essay →Try the MCP server I would actually trust in prod.
The database client that knows your project. $79 one-time. All your Macs.