Performance & Latency

Connection Pool

Also known as: database connection pool, pooling

Definition

A connection pool keeps a fixed set of open database connections and lends them to requests, avoiding per-request handshake cost and bounding concurrency at the database. Pool size is a throughput ceiling, not a comfort setting: it caps how many queries can be in flight at once.

Last reviewed · Part of the Architecture Glossary

In practice

Little's Law sizes it. A pool of 20 connections against queries averaging 5 ms sustains 20 / 0.005 = 4,000 queries/s. Anything beyond that queues for a connection, and that wait shows up as application latency with no slow query in the database log — one of the more confusing debugging sessions available.

Bigger is not better. PostgreSQL allocates per-connection memory and its scheduler degrades past a few hundred backends; the usual guidance lands around cores × 2 + effective_spindles, which is a much smaller number than most defaults suggest. Above that, add PgBouncer in transaction mode instead of raising the pool.

The arithmetic that bites in Kubernetes: 40 pods × a pool of 25 = 1,000 connections requested from a database configured for 200. Pool size is per process, and the fleet multiplies it.

When it matters

Every deployment-size change, every autoscaling policy, every serverless function that opens its own connection (where a proxy is effectively mandatory).

Common mistake

Setting the connection-acquisition timeout to infinity. Under saturation, requests pile up waiting for a connection and the service dies of thread exhaustion rather than rejecting work. A short acquire timeout turns that into honest backpressure.

See also

Go deeper