What Actually Happens When Your Database Runs Out of Connections

A database like Postgres allocates a fixed maximum number of connections, often a few hundred by default, and each one holds real memory and a real process on the database server. Every application server in your fleet typically opens its own pool of connections, so your total connection count scales with your app server count, not with your actual query load. Add five more app servers during a traffic spike, each opening twenty connections, and you've just asked the database for a hundred more connections at the exact moment it's already under load. The database doesn't queue the excess gracefully; it starts rejecting new connections outright.

A pooler like PgBouncer sits between your application servers and the database and maintains a much smaller, fixed pool of real database connections, handing them out to app servers on a per-query or per-transaction basis instead of per-server. Your application code still thinks it's opening a normal connection; the pooler is the one deciding how many actual connections the database sees. This decouples your application server count from your database connection count, which is exactly the coupling that caused the problem in the first place.

Poolers typically offer a few modes, and picking the wrong one causes subtle bugs:

• Session pooling assigns a connection to a client for its whole session. Safest for compatibility, but barely reduces connection count.
• Transaction pooling assigns a connection only for the duration of a transaction, then returns it to the pool. This is where most of the connection-count savings come from, but it breaks features that rely on session state, like prepared statements or session-level advisory locks, unless your ORM is configured to avoid them.
• Statement pooling returns the connection after every single statement. Most aggressive, most restrictive, rarely the right default.

For most application workloads, transaction pooling is the right starting point, with a careful audit of anything in your ORM or query layer that assumes session state survives between queries.

A pool that's too small just moves the bottleneck from the database to the pooler's own queue. A pool that's too large defeats the purpose. A reasonable starting point is to size the pool close to the number of CPU cores on your database server, since that roughly matches how many queries the server can genuinely execute in parallel; going meaningfully higher rarely improves throughput and just adds contention. From there, watch actual wait times in the pooler's stats and adjust based on measured queueing, not intuition.

A pooler fixes connection count, not every connection-related problem. Long-running transactions still hold a pooled connection for their entire duration, so a slow report query can still starve the pool for everyone else. Migrations that run DDL against a live table can still lock things up regardless of pooling. And if your read replica lag is already a problem, pooling doesn't touch that at all, it's a separate issue with a separate fix. Treat the pooler as solving exactly one problem: too many raw connections, not as a general database performance fix.

Introducing a pooler into a live system is itself a risk if you do it all at once. Start by pointing a single, low-traffic service at the pooler instead of the database directly, and compare its error rate and latency against the services still connecting directly. Watch specifically for anything that depends on session state: temporary tables, session-level configuration changes, or advisory locks used for something other than job deduplication. Once that first service runs clean for a few days under real traffic, move the next one, and keep a fast rollback path, pointing the connection string back at the database directly, available the whole time.