# Read-only Postgres access can still take down your application

> Source: <https://dev.to/mads_hansen_27b33ebfee4c9/read-only-postgres-access-can-still-take-down-your-application-3l6m>
> Published: 2026-07-22 01:21:34+00:00

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:

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](https://conexor.io/blog/mcp-server-postgres-workload-isolation?utm_source=devto&utm_medium=article&utm_campaign=content)