Why does my database connection pool run out of connections?

Pool exhaustion means connections are being taken out and not returned as fast as they are requested. The symptom is a request that hangs and then times out waiting to acquire one, and it typically appears under load rather than in testing. There are only a few underlying causes, and distinguishing them matters because the fixes differ completely.

The most common is a leak. A connection is checked out and never released, usually because an error path returns early and skips the release, or because the release is not in a construct that runs regardless of outcome. Each failed request permanently reduces the pool until nothing is left. The tell-tale sign is that the problem worsens over time and a restart temporarily fixes it.

The second is queries that are simply slow. If each connection is held for seconds, a modest pool saturates at a low request rate even though nothing is leaking. Here the pool is reporting a problem elsewhere, and enlarging it only moves the queue into the database.

The third is a pool genuinely too small for the traffic, which is the only case where raising the limit is the right answer. Even then there is a ceiling, because the database has its own maximum connection count and exceeding it fails harder. Running several application instances multiplies your pools against that single server limit, which is easy to forget when scaling out.

Long-running transactions deserve special mention. A transaction holds its connection for its entire lifetime, so opening one and then performing slow work inside it, particularly a network call, ties up a connection far longer than the queries justify.

Monitoring pool utilisation and checkout wait time turns this from a mystery into an obvious signal well before it becomes an outage.