How to connect Claude to Postgres without giving it write access

I went to connect Claude to Postgres the way most tutorials show, with the official MCP server. It turns out that server is archived, and its read-only guard can be bypassed with one stacked query. This is the setup I'd use instead, and where it stops being enough once a second person starts asking questions.

Step 1: create a read-only user, on a replica

Do this before any MCP config.

CREATE ROLE claude_ro LOGIN PASSWORD '<generated>';
GRANT CONNECT ON DATABASE mydb TO claude_ro;
GRANT USAGE ON SCHEMA public TO claude_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_ro;

ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO claude_ro;

The ALTER DEFAULT PRIVILEGES line is what stops new tables from being invisible next month. Default privileges only cover objects created by the role that set them, so if your migrations run as a different user, run it as that user.

Step 2: skip the official server

The package most tutorials still show is @modelcontextprotocol/server-postgres. Don't use it.

Step 3: run a maintained server

We wrote a replacement: @contextflo/postgres-mcp, open source under MIT. It's a drop-in swap for the archived server, with the same query tool and the connection string as the first argument.

npx @contextflo/postgres-mcp postgresql://claude_ro:pass@replica-host:5432/mydb

In Claude Code:

claude mcp add postgres -- npx -y @contextflo/postgres-mcp postgresql://claude_ro:pass@replica-host:5432/mydb

In Claude Desktop:

// claude_desktop_config.json
{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@contextflo/postgres-mcp",
        "postgresql://claude_ro:pass@replica-host:5432/mydb"
      ]
    }
  }
}

Read-only is enforced in four layers, and each one stops the stacked-query exploit on its own. The exploit is a test case in the repo.

1. User SQL goes over Postgres's extended query protocol, so Postgres itself rejects multi-statement input.
2. The connection starts with default_transaction_read_only=on, and every statement runs inside BEGIN READ ONLY and ends in ROLLBACK.
3. Statements are checked against an allowlist using the real Postgres parser, walking the whole tree, so a data-modifying CTE hidden inside a SELECT gets caught.
4. The read-only role from Step 1, which Postgres enforces no matter what the code above gets wrong.

It's v0.1.0, and it has limits. The parser can't see inside your own functions, so a SECURITY DEFINER function called from a SELECT can do whatever its body does. That's why the read-only role isn't optional. Setup details and the full list are on the postgres-mcp page. If you'd rather use something we didn't write, @bytebase/dbhub also runs with npx and a read-only DSN.

Once connected, Claude can read the schema and run SQL. Ask "how many users signed up this week?" and it writes the query and answers. For one person exploring a schema they already know, that's all you need.

Where it breaks for a team

Nothing fails loudly. The answers just start to drift.

The answers stop agreeing

Production Postgres schemas are messy. They grow over years, with abbreviated column names, legacy tables and business logic nobody wrote down. Claude sees this:

usr_acct (id, sts, crt_at, upd_at, tier_id, ref_src, acq_ch)
ord       (id, usr_id, amt_gross, amt_net, disc_cd, sts, crt_at)
sub       (id, usr_id, plan_id, mrr_cents, churn_at, cancel_rsn)

Without context it guesses. Does amt_net include tax? Which values of sts mean completed?

Your head of growth asks what revenue was last week, and Claude computes it from ord.amt_net. Your finance lead asks the same question and gets a different number, because their notes say something else. Both numbers look confident, and nobody knows they disagree until they're in the same meeting.

The context becomes somebody's second job

The notes workaround works. It also means context is maintained by hand. A column gets renamed, a table gets added, a metric definition changes, and someone has to remember to update the notes in every teammate's separate project.

The config sprawls

• Everyone edits a JSON file containing database credentials. Your head of ops isn't doing that.
• Everyone gets identical access. Restricting who sees what means a separate Postgres user per person, with the grants and rotation that come with it.
• Credentials sit on laptops in plaintext. Revoking one person means changing the password for everyone.
• Changing provider breaks everybody. Move from Supabase to Neon, or RDS to Railway, and every person updates their config.
• There's no record of what ran, who asked, or whether the answer was right. Our server can keep a local query log, but only on the machine it runs on.

The simpler path for a team

Contextflo connects to Postgres once, with read-only credentials, and runs the MCP server for you. It reads the schema plus any source code and docs you point it at, and generates what each table and column means, how they relate, and how key metrics are calculated. Your team still asks questions in Claude. What changes is what Claude knows, and who's allowed to ask what.

It works with any hosted Postgres: AWS RDS, Supabase, Neon, PlanetScale, Google Cloud SQL, Azure Postgres, Railway, Render, or self-hosted.

The generated context is a draft. It gets structure right and business meaning wrong often enough that someone who knows the data should read it once. Reviewing it takes an afternoon, where writing it from scratch takes weeks.

Which one to use

If you want Claude to query Postgres yourself, run a maintained server against a replica with a read-only role, and you're done. If your team is going to make decisions on the answers, something has to hold the context in the middle.

Here is a more in-depth look at Contextflo and how it works.