The best PostgreSQL MCP server is the one that survives negative tests

Every PostgreSQL MCP server looks capable in the first five minutes.

The client connects. The model lists tables. A question becomes SQL, and a plausible result comes back.

The differences appear later:

• a tenant filter is missing
• a schema changes
• a query scans too much data
• the database role is broader than expected
• someone asks where yesterday's number came from

So I would not evaluate a PostgreSQL MCP server by demo speed alone.

I would score seven things:

1. Database-enforced authority — read-only and object scope must live in PostgreSQL, not only in a prompt.
2. Bounded tools — explicit parameters, row limits, timeouts, cancellation, and structured errors.
3. Current context — schema, relationships, approved views, sensitive fields, and metric definitions.
4. Tenant isolation — identity and scope must survive every tool call.
5. Result receipts — source, filters, freshness, row count, truncation, and trace ID.
6. Failure behavior — pooling, retries, lock waits, TLS failures, and schema drift.
7. Versioned portability — predictable contracts across MCP clients and upgrades.

Then run negative tests.

Try an excluded table. Omit the tenant. Request a mutation. Force a timeout. Change the schema. Ask for more rows than the limit.

The best server is not the one that completes the happy path.

It is the one that fails unsafe requests clearly and predictably.

Full scorecard: Best MCP server for PostgreSQL