Postgres MCP servers: which one to use and how to lock it down

Published May 5, 2026 by Pondero Editorial

Hand-drawn illustration of an AI client connecting to Postgres through three MCP server options — Three MCP servers, one Postgres database, and a lockdown checklist that keeps your LLM out of `DROP TABLE`.

In short

A Postgres MCP server lets an LLM client (Claude, Cursor, or any MCP-aware app) read or write Postgres. There are three credible options in April 2026: the official server in the modelcontextprotocol/servers monorepo, the Supabase-published MCP, and a small set of community servers. The right pick depends on your stack: official for vendor-neutral, Supabase if you already host on Supabase, community if you need a feature the others lack. This guide is a vendor-neutral framework for the picking, plus a four-step lockdown checklist that turns “AI can run SQL” into “AI can run SQL safely.” We have not run a head-to-head security audit; treat the lockdown checklist as a starting baseline, not a certified hardening guide.

What a Postgres MCP server is and why you would want one

The Model Context Protocol (MCP) is an open spec for giving LLM clients structured access to external systems through standardized servers. A Postgres MCP server exposes your database to the client as a set of MCP tools: list_tables, describe_schema, run_query, and so on.

Why you would want one: the LLM stops guessing at your schema and starts answering questions from your actual data. Real questions like “what is the conversion rate for users who signed up last week?” become a tool call against your warehouse instead of a hallucinated number.

The cost: any MCP server with SQL access is one prompt-injection away from DROP TABLE. The lockdown section below is what keeps that hypothetical out of your incident channel.

For the MCP 1.0 spec status, see modelcontextprotocol.io/specification.

Three options in April 2026

Postgres MCP options matrix — Official is the safe default. Supabase wins if you already host there. Community options unlock special cases.

Official postgres MCP server (modelcontextprotocol/servers)

Lives at github.com/modelcontextprotocol/servers/tree/main/src/postgres. Maintained by the MCP project itself. Connects via standard Postgres connection string. Exposes read-only tools by default.

When to pick: any vanilla Postgres setup (RDS, self-hosted, Cloud SQL, anything with a connection string). Vendor-neutral, no lock-in, deepest documentation. Our default recommendation for most teams.

What you get: list_tables, describe_table, list_schemas, run a read-only query. The tool surface is small and predictable, which is what you want for an MCP server with database access.

What you do not get: write capabilities by default. If you need INSERT/UPDATE for the agent, you have to wrap a separate tool with explicit allowlisting.

Supabase MCP

Lives in the Supabase docs and ships as part of the Supabase developer workflow. See supabase.com/docs/guides/getting-started/mcp for the current setup steps.

When to pick: you are already on Supabase. The MCP server inherits Supabase’s row-level security policies, which means the lockdown work you have already done at the database layer carries over to the MCP surface.

What you get: schema introspection, query execution, and integration with Supabase auth and RLS. Setup is faster than the official server because Supabase handles the connection plumbing.

What you do not get: portability. Switching off Supabase later means switching MCP servers as well.

Crystal DBA pg-mcp / community options

The community Postgres MCP servers (Crystal DBA’s pg-mcp and a handful of others on GitHub) target specialized use cases: query plan introspection, SQL formatting, multi-database routing, and so on.

When to pick: your use case needs a feature the official server does not offer. Examples: you want EXPLAIN plans surfaced as a separate tool, you want the LLM to be able to query metadata across multiple databases in one call, or you want SQL safety validation built in.

What you get: depends on the specific server. Read each project’s README before adopting.

What you do not get: the maintenance commitment of the official server. Community projects come and go.

Setup walkthroughs (least-privilege)

The general pattern across all three options: create a dedicated database role for the MCP server, grant only the minimum privileges needed, and connect the MCP server with that role’s credentials. Never connect with your superuser or your application’s main role.

For the official server, this looks roughly like:

Create a role: CREATE ROLE mcp_readonly LOGIN PASSWORD '<strong-password>';
Grant connect: GRANT CONNECT ON DATABASE <db> TO mcp_readonly;
Grant schema usage: GRANT USAGE ON SCHEMA public TO mcp_readonly;
Grant select: GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_readonly;
Set default privileges so future tables inherit: ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO mcp_readonly;
Configure your MCP server with the connection string for mcp_readonly.

For Postgres role-based access docs, see postgresql.org/docs/current/user-manag.html.

For Supabase, the equivalent is configuring an RLS policy that scopes the MCP role to the rows it should see. Supabase’s docs walk through the exact SQL.

Lockdown checklist

Read-only lockdown flow — Four steps from "AI can run SQL" to "AI can run SQL safely." None are optional.

These four controls apply across all three MCP server options. Skip any of them at your own risk.

1. Read-only role + statement_timeout

Create a dedicated read-only role for the MCP server (not your application role, not a superuser). Set a statement_timeout on the role so a runaway query gets killed:

ALTER ROLE mcp_readonly SET statement_timeout = '5s';

Five seconds is aggressive. Pick a value that lets your normal MCP queries complete and kills anything pathological.

2. Schema allow-list

Do not give the MCP role access to every schema. Pick the schemas the LLM should see (typically your data warehouse or read replica schema, not your auth tables) and grant SELECT only on those. Revoke USAGE on schemas the role should not touch.

If your auth or PII tables live in the same database as the data you want the LLM to see, this is the step that prevents prompt-injection attacks from querying user passwords. Do not skip it.

3. Connection-pool limits

Set a connection limit on the role:

ALTER ROLE mcp_readonly CONNECTION LIMIT 5;

Five connections is enough for one or two MCP clients. Without a limit, a misbehaving client can exhaust your connection pool and take down your application.

4. Audit logging

Enable Postgres logging for the MCP role’s queries (log_statement = 'all' scoped to the role via ALTER ROLE). Ship the logs somewhere queryable. When something goes wrong, the audit trail tells you what the LLM ran.

This is the control that turns “we think the AI did something weird” into “the AI ran this exact query at this timestamp.” Cheap insurance.

Three real workflows it shines for

Internal analytics chat: ops or product team asks the LLM “what was our DAU last week” or “show me churn by cohort.” Read-only Postgres MCP against your warehouse handles this without the LLM hallucinating numbers.

Schema-aware code generation: developer asks Cursor or Claude to write a SQL query against the live schema. The MCP server gives the LLM the actual table definitions instead of hoping the model remembers.

Bug triage: support agent asks “what is the order state for customer X” and the LLM looks it up. Faster than spinning up Metabase for a one-off question, and the LLM can chain follow-ups.

When NOT to give an LLM SQL access

Skip a Postgres MCP server (or pick a much narrower tool) when:

Your database has PII you cannot easily isolate behind a separate role/schema
Your LLM client is exposed to untrusted input (public chat surface, external customers)
You do not have the engineering capacity to maintain the role separation and audit logging
Your data team has not signed off on the access model

In these cases, build narrow purpose-built tools (a “lookup customer order” tool that takes only a customer ID) instead of giving the LLM full SQL.

What we cannot tell you

We have not run a controlled security audit on these three Postgres MCP servers. The lockdown checklist is a starting baseline based on Postgres role-based access best practices and our own production setup; it is not a certified hardening standard. A real audit would test prompt-injection scenarios end-to-end, validate the role privilege boundaries, and probe the audit-log coverage.

For the wider MCP server landscape, see our best MCP servers April 2026 update. For client-side picks, see MCP client comparison April 2026 update. For an end-to-end MCP build walkthrough, see building your first MCP server with Pipedream.

FAQ

Is the official MCP Postgres server free? Yes. It is open source under the same license as the rest of the modelcontextprotocol/servers monorepo.

Do you need MCP 1.0 to use these servers? The current servers target MCP 1.0. Verify the spec status at modelcontextprotocol.io/specification before adopting; the protocol has shipped breaking changes during 1.x.

Can you write to Postgres through MCP? Yes, but it is a footgun without strict allowlisting. The default for all three options is read-only. If you turn on writes, scope to specific tables and audit every call.

What clients support Postgres MCP? Any MCP-aware client. Claude Desktop, Cursor, Cline, Continue, and others. See MCP client comparison.

Verdict

Pick the official Postgres MCP server unless you are on Supabase (in which case pick the Supabase MCP) or you need a community-server-only feature. Then run the four-step lockdown before connecting any LLM client. Read-only role, schema allow-list, connection limit, audit logging. None of those steps are optional, and none of them are hard.

For the wider MCP picture, see best MCP servers April 2026 update.