I built a read-only Postgres MCP server so I could point Claude at prod without fear

Mohamed amine Atil — Tue, 02 Jun 2026 14:21:05 +0000

The Model Context Protocol (MCP) lets AI assistants like Claude and Cursor connect to real systems — including your database. The problem: most setups hand the AI a connection string with full write access, and rely on the model choosing not to run a DELETE without a WHERE.

That's the part I wanted to remove. Not "the AI probably won't write" — "the AI can't write." So I built BoltSchema: a Postgres MCP server that's read-only by default and structurally can't modify your database. Here's how it works under the hood.

The threat model

The scary part of AI + database access isn't the AI being malicious. It's:

A hallucinated UPDATE that "fixes" a row.
A DROP TABLE suggested confidently during a "cleanup."
SQL injection through a tool call you didn't sanitize.

Read-only credentials are the obvious answer — and everyone means to set them up. But read-only-by-discipline breaks the one time you forget, or grab the wrong connection string. I wanted read-only to be the default, enforced at multiple layers.

Defense in depth

Layer 1 — Read-only transaction on every query.

Every single query runs inside:

BEGIN READ ONLY; -- your query COMMIT;
Even if someone hands the server a superuser connection string, Postgres itself refuses any write inside a READ ONLY transaction. The database is the last line of defense, and it doesn't trust my code.

Layer 2 — A SQL guard that isn't fooled by string literals.

A naive keyword blocklist is trivially bypassed — SELECT 'DROP TABLE users' would trip a dumb filter, and '; DROP TABLE-- would slip past one. So the guard:

Strips comments and string literals (single-quoted, double-quoted, and dollar-quoted) first,
Then keyword-matches against a banlist (DROP, DELETE, INSERT, UPDATE, ALTER, TRUNCATE, GRANT, …),
Rejects multi-statement payloads outright.
So you can't smuggle a forbidden keyword inside a literal, and you can't chain a second statement.

Layer 3 — Encryption at rest.

Connection strings are encrypted with AES-256-GCM (random IV + auth tag per record). Token comparison uses timingSafeEqual to avoid timing attacks.

Layer 4 — Result limits.

Queries are wrapped in a LIMIT (default 100, hard cap 1000) so a SELECT * on a huge table doesn't blow up the context window or the connection.

What it exposes to the AI

Two MCP tools:

get_database_schema — lists tables + columns from information_schema (system schemas excluded).
execute_read_only_query — runs SQL through the guard + read-only transaction.

The transport

It speaks MCP Streamable HTTP (the modern SSE-based transport that supersedes the deprecated SSEServerTransport), built on the official @modelcontextprotocol/sdk. Native streamable-HTTP clients point at the URL directly; stdio-only clients (like Claude Desktop) use the mcp-remote bridge.

Try it without connecting your own DB

There's a zero-trust sandbox: one click seeds a realistic e-commerce Postgres database (customers, products, orders, …) and hands you a public token you can paste straight into Claude Desktop. No signup, same read-only guard as production.

🔗 Built by me — try BoltSchema here: link
🐦 Questions or feedback? I'm on X: @atilmohamine

DEV Community: Mohamed amine Atil