Database Connection Pool Exhaustion

An application needs a database connection to talk to the database. Creating one from scratch is expensive, so applications keep a small pool of reusable connections instead.

A database connection is a stateful, authenticated session between the application and the database. Opening one involves a TCP handshake, authentication, and session setup — doing that for every single query would be slow and wasteful.

So instead, the application maintains a connection pool: a fixed number of pre-established connections that requests borrow, use, and return.

A pool has a fixed size. For example, pool size = 10 means at most roughly 10 connections can be actively in use at the same time, depending on the implementation and configuration.

The pool doesn't shrink. Connections simply get held for longer than the rate of incoming requests can tolerate — because concurrency spikes, queries run longer, transactions stay open, or borrowed connections never return.

Whichever cause it is, the observable symptom is identical: all connections busy, requests waiting. That's why diagnosing this failure means looking past the pool itself and asking what's actually holding the connections. A common severe variant is a long transaction: the application opens a transaction, then waits on some external call or extra application work before commit or rollback. Even if the individual SQL statements are fast, that connection stays checked out for the full transaction lifetime.

Press play to watch a healthy pool get exhausted three different ways — traffic, slow queries, and a connection leak — then recover once the real bottleneck is fixed.

The database can look completely healthy while the application is failing every request — which makes this failure mode unusually confusing to diagnose under pressure.

Because the bottleneck sits between the application and the database, engineers checking database dashboards first often see nothing wrong — low CPU, normal disk I/O — while requests are queued waiting to borrow a connection. What the caller usually sees is a connection acquisition timeout — failing to get a connection from the pool in time — which is different from a query timing out inside the database.

Increasing pool size can look like an instant fix — waiting requests disappear. But it doesn't remove work, it just relocates it.

Suppose (illustrative numbers) the pool is sized at 10 and we bump it to 100. Waiting requests drop immediately, because there are now far more connections to borrow. That looks like a win.

But those 100 connections all eventually run queries against the same database. Every application instance contributes to the database's total connection count, and the database itself has a hard ceiling such as PostgreSQL's max_connections. If the queries were already slow, the database now has to process 100 concurrent slow queries instead of 10 — increasing CPU, memory, I/O, and lock contention rather than removing the real bottleneck. For the database-side operational view, see Postgres Production Engineering.

There are five common strategies. Most real incidents need a combination, not just one.

During a real incident, a small set of signals tells you where to look first.

Watch: active connections, idle connections, pool utilization, waiting requests, connection acquisition time, query execution time, query count, database CPU, database connection count, and connection timeout errors.