Fixing 'Too Many Connections' Without Just Raising the Limit

A common pattern: connection count climbs slowly through the day, nothing looks wrong at normal traffic, and then a batch job or a burst of background workers pushes it over the edge overnight when nobody's watching a dashboard. By the time anyone notices, the database has been rejecting new connections for a while and every service touching it is throwing errors.

The mistake is treating this as a capacity problem. A slow, steady climb in connection count almost never means you need more capacity. It means something is opening connections and not giving them back, and more capacity just gives the leak more room to run before it matters.

Three layers can each be holding connections open: your application's own connection pool in the ORM or driver, a pooler like PgBouncer sitting between the app and the database, and Postgres itself. Confusing these layers is the most common reason a fix doesn't work. Raising your app's pool size does nothing if PgBouncer is the layer that's exhausted. Raising PgBouncer's pool does nothing if Postgres itself is capped lower.

Check all three independently: your app framework's pool metrics, PgBouncer's SHOW POOLS output if you're running it, and Postgres's own pg_stat_activity. Whichever one is actually maxed out first tells you where the real bottleneck is, and it's often not the layer closest to the alert that fired.

Query pg_stat_activity for connections that have been idle in a transaction for more than a few minutes. That state, idle in transaction, is the single most common cause of a slow connection leak: a request started a transaction, did some work, and then never committed or rolled back, usually because of an exception path that skips cleanup or a connection returned to the pool without the driver closing the transaction first.

Group the idle connections by application name or query text if your driver sets one. That usually points straight at the endpoint or background job responsible, rather than leaving you guessing across the whole codebase. Fix the code path first. A pool sized correctly around a leak just runs out slower.

Once the leak is fixed, size the pool by what your database can actually serve, not by how many concurrent requests your app might see. A single Postgres instance on typical hardware serves a surprisingly small number of connections well; each one carries real memory overhead, and pushing past what the CPU and disk can actually process just means requests wait longer inside the database instead of failing fast at the pool.

The rule of thumb that holds up in practice: size connections around available CPU cores plus a margin for background jobs, not the peak number of app instances you might scale to. If you need to support more concurrent app connections than that, put a pooler in front of Postgres rather than raising Postgres's own connection ceiling.

If you're adding a pooler, the mode setting matters more than the pool size:

• Session mode assigns a database connection to a client for the whole session, which supports every Postgres feature but gives almost no multiplexing benefit.
• Transaction mode returns the connection to the pool as soon as a transaction commits, letting far more clients share the same small set of database connections.
• Transaction mode breaks features that depend on session state persisting across queries: prepared statements, session-level advisory locks, and some ORMs' connection-level settings.
• Test your actual query patterns against transaction mode before rolling it out, since the failure mode is often a confusing error in production rather than a clean startup failure.

Most teams that switch from session to transaction mode see their effective pool capacity increase substantially, but only after finding and fixing the handful of queries that assumed session state would persist.