Read-only Postgres access can still take down your application

An MCP server for Postgres can be read-only and still hurt production.

Exploratory joins, wide aggregates, synchronized schedules, and concurrent retries consume the same connections, CPU, memory, I/O, and replica capacity as the application.

Read-only describes mutation authority.

It does not describe workload safety.

Treat AI database traffic as a separate workload class:

• use a dedicated least-privilege database role
• give it a separate, bounded connection pool
• enforce acquisition, statement, lock, row, and byte limits
• route suitable reads to a replica with an explicit freshness contract
• propagate deadlines and cancellation to Postgres
• cap retries and jitter scheduled work
• reject or defer work when the budget is exhausted

The pool is an admission controller, not just a connection reuse optimization.

And a replica is not free capacity. Lag, long snapshots, replay conflicts, and I/O still need an operational budget.

The safe overload response is visible and bounded. It is not silently widening the pool, switching to the primary, or retrying until the user gets an answer.

Full guide: MCP server for Postgres: isolate AI workloads from OLTP traffic