PgBouncer in Production: A Connection Pooling Checklist

Postgres reserves a fixed chunk of memory per connection for things like sort buffers and cached query plans, and the default max_connections setting is deliberately conservative. Add an autoscaling app tier, or a burst of short-lived serverless invocations each opening their own connection, and you can exhaust that ceiling long before the database is doing meaningful work.

A connection storm often follows a deploy or a traffic spike: new instances all boot at once and each opens its full pool immediately, rather than ramping up gradually.

Session pooling hands a client one dedicated backend connection for the life of its session, which is safe but doesn't multiply capacity much. Transaction pooling shares a small set of backend connections across many clients, checking a connection back into the pool between transactions instead of between sessions, which is where the real capacity gain comes from.

That gain has a cost: anything scoped to a session rather than a transaction, prepared statement caching, advisory locks, SET commands, LISTEN and NOTIFY, can behave incorrectly under transaction pooling because the next statement might land on a different backend connection entirely.

Set the pooler's default_pool_size based on what the database can actually sustain, not a round number that felt safe. If you run several logical pools against one Postgres instance, their sizes need to add up to something the instance's own max_connections can hold, with headroom for administrative connections.

Watch pool wait time as the signal that matters, not database CPU. A pool that's too small shows rising wait time for a free connection well before the database itself looks stressed, which is exactly the early warning you want.

• Audit application code for anything that depends on session-level state: advisory locks, prepared statement caching, LISTEN and NOTIFY.
• Put the pooler in front of a read replica first, where the blast radius of a mistake is smaller.
• Record pool wait time before and after the change so you have a real before-and-after comparison, not a guess.
• Set a client-side statement timeout so one stuck query can't hold a pooled connection hostage indefinitely.

• Pointing every service at one shared pooler instance with no per-service limit, so a noisy service can starve a quiet one.
• Forgetting that schema migrations generally need a direct connection, because DDL statements don't behave well under transaction pooling.
• Watching database CPU as the health signal instead of watching pool saturation, which hides the actual bottleneck until it's already an outage.

Some teams run PgBouncer per application instance in addition to a shared pooler in front of the database, usually to smooth out very bursty local connection patterns before they ever reach the shared layer. That extra hop adds a small amount of latency to every query, so it's worth the added complexity only when the shared pooler is genuinely the bottleneck, not by default.

Whichever layout you land on, keep the pooling topology documented somewhere every engineer can find, including which mode each layer runs and why. A pooler that silently switched from session to transaction mode during an unrelated configuration change is a common way teams rediscover the session-state gotchas months after everyone forgot they existed.

Review the pool configuration whenever the underlying database instance size changes too. A pool sized correctly for a smaller instance can quietly become the bottleneck after an upgrade if nobody revisits default_pool_size to match the new headroom, leaving capacity on the table that the database could actually serve.