Your MCP connection pool is an admission-control system

An MCP database server can be read-only, well scoped, and still take production down.

The failure path is familiar:

1. several agents call tools at once
2. each tool borrows a database connection
3. a few queries run longer than expected
4. the pool fills
5. callers queue
6. retries turn a burst into sustained pressure

The pool size is not just a performance setting. It is an admission-control decision.

Start with the database budget, after reserving capacity for the application, administration, migrations, monitoring, and incidents. Then divide that budget across the maximum number of MCP server replicas.

Measure demand from tool executions, not chat sessions:

• peak concurrent tools
• connections held per tool
• p50/p95/p99 hold time
• queue, timeout, cancellation, and retry rates

When demand exceeds the database budget, the answer is a bounded queue and clear overload behavior, not a larger number copied into every replica.

Also separate fast metadata tools from expensive analytical tools. One slow aggregation should not make health checks and bounded lookups unavailable.

Finally, test the exact driver, PgBouncer mode, TLS path, role, and query mix used in production. Then exhaust the pool and interrupt the database on purpose.

A healthy system should reject excess work clearly, release cancelled connections, and avoid synchronized retries.

Full guide: MCP database connection pool sizing