MCP field guide / PostgreSQL
// mcp field guide · data
Two servers share this name and the difference is the whole story: a read-only reference server where a guard is near-ceremony, and write-capable servers where a single tool call can DROP TABLE. Here's the sourced breakdown — and an honest read on where a human-approval layer earns its keep.
GUARD FIT · READ-ONLY SERVER
WEAKA server that can only run SELECTs inside a read-only transaction has nothing destructive to gate. A guard here is mostly ceremony.
GUARD FIT · WRITE-CAPABLE SERVER
STRONGThe moment execute_sql can write, one call can DROP/TRUNCATE/DELETE — unbounded, usually unrecoverable. A pre-commit human checkpoint is high-value.
Overall fit: WEAK → STRONG — near-ceremony for the read-only reference server, essential the moment the server can write.
There is no single "PostgreSQL MCP server." Two matter, and they sit at opposite ends of the risk spectrum:
1. The official reference server — @modelcontextprotocol/server-postgres, maintained by the Model Context Protocol project. Its own description: "read-only access to PostgreSQL databases, enabling LLMs to inspect schemas and execute read-only queries." It was deprecated and archived in 2025 (moved to the servers-archived repo), though it still sees significant weekly npm downloads.12
2. Postgres MCP Pro — crystaldba/postgres-mcp, by Crystal DBA (MIT). The actively-maintained, write-capable successor pattern: "configurable read/write access and performance analysis for you and your AI agents." It adds index tuning, EXPLAIN plans and health checks — and, in unrestricted mode, full read/write SQL.3 Major DB vendors (Supabase, Neon) now ship write-capable MCPs too; the read-only reference server is the historical exception, not today's norm.
| Tool | Risk | What it does |
|---|---|---|
| query | read-only | Executes SQL inside a READ ONLY transaction; schemas exposed as resources. No mutation by design. |
Honest caveat: a 2025 Datadog Security Labs case study documented a read-only bypass in an earlier reference PostgreSQL MCP server — the now-archived @modelcontextprotocol/server-postgres (v0.6.2) — where a multi-statement string like COMMIT; DROP SCHEMA public CASCADE; could escape the read-only transaction.4 "Read-only" was the intent, but breakable in that version (not the Crystal DBA server above). It illustrates a general point: the safety property you care about should be enforced where the statement actually runs, and a readable impact diff on the real SQL is exactly what surfaces a "query" that is secretly a DROP.
| Tool | Risk | What it does |
|---|---|---|
| list_schemas | read-only | List database schemas. |
| list_objects | read-only | List tables, views and other objects. |
| get_object_details | read-only | Inspect an object's columns, constraints, indexes. |
| explain_query | read-only | Return the query plan for a statement. |
| get_top_queries | read-only | Report the slowest / most frequent queries. |
| analyze_workload_indexes | read-only | Recommend indexes for the workload. |
| analyze_query_indexes | read-only | Recommend indexes for specific queries. |
| analyze_db_health | read-only | Health checks (bloat, vacuum, connections…). |
| execute_sql (restricted) | read-only | In --access-mode=restricted: runs in a read-only transaction, rejects commit/rollback. |
| execute_sql (unrestricted) | mutating destructive | In --access-mode=unrestricted: full read/write — INSERT/UPDATE, and also DELETE, DROP TABLE, TRUNCATE, arbitrary DDL. |
The critical detail: there is no separate "destructive" tool. All the risk lives inside one execute_sql tool, gated only by which access mode the operator chose at launch. Once it's unrestricted, the model decides what SQL to run — and a DROP looks like any other call.
Analytics / read (reference server or restricted mode). An agent inspects schemas and runs SELECTs — "what were last quarter's top accounts?" No mutation risk by design.
Agent-driven writes (Pro, unrestricted). A dev agent seeds or corrects data with INSERT/UPDATE via execute_sql.
Autonomous migrations (Pro, unrestricted). An agent applies DDL — ALTER TABLE, index changes, DROP — guided by analyze_workload_indexes. This is exactly where a mis-targeted or unbounded statement becomes irreversible.
The verdict splits, and the split is the recommendation:
Read-only server → weak fit. If it can only run SELECTs in a read-only transaction, a human checkpoint gates almost nothing — there's no mutation to compensate, nothing irreversible to catch before commit. Saying so plainly matters: for a correctly-behaving read-only DB MCP, a guard is close to ceremony, and we'd rather tell you that than sell you a checkbox.
Any write-capable database MCP → strong fit. The instant execute_sql can write, one tool call can DROP TABLE, TRUNCATE, or fire an unbounded DELETE/UPDATE — the canonical catastrophic action, usually unrecoverable without a backup. A guard that shows the exact statement and a readable impact diff before commit, and holds destructive calls for a human, is high-value precisely because the blast radius is unbounded and the server's own safety is a coarse launch-time switch, not per-statement approval.
For an irreversible DROP/TRUNCATE there's no compensation to run — nothing can un-drop a table with no backup. The guard's job there isn't a magic rollback; it's the pre-commit human checkpoint and an honest "this cannot be undone" flag before you approve. That honesty — compensation is not undo — is the point.
Drop ChronoMCP in front of any MCP server and gate the destructive SQL on a human. Zero rewrite, MIT.
Read the quickstart → More MCP profilesquery tool, READ ONLY transaction, archival): github.com/modelcontextprotocol/servers-archived/tree/main/src/postgres@modelcontextprotocol/server-postgres: npmjs.com/package/@modelcontextprotocol/server-postgresProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with these projects. Capabilities and status reflect sources current as of Aug 2026 and can change — check the source links for the latest.