Covers the specific signature of a client-side leak — pool usage climbing steadily under sustained normal traffic rather than in a burst — and the try/finally fix. Does not cover a pool that's simply undersized for a legitimate concurrent burst at startup; that's the connect-timeout playbook, a different pattern in the same counters.
Unverifiedno reproductions yetWhy this confidence?8 steps. Every step is written out below in full — the interactive version simply follows the branches for you.
Unlike a startup burst, this climbs steadily over time under otherwise ordinary load and doesn't recover on its own.
What happens next
Sample repeatedly across several minutes of normal traffic rather than at a single instant.
console.log({ total: pool.totalCount, idle: pool.idleCount, waiting: pool.waitingCount });Expected result
{ total: 10, idle: 0, waiting: 37 }What happens next
If idleCount stays pinned at 0 and waitingCount keeps growing across ordinary, non-bursty traffic, connections are being checked out and never returned. Every pool.connect() must be matched with client.release(), including on every error path — a thrown/rejected query, an early return, or an unhandled exception between connect() and release() leaves that client permanently checked out, and the pool has no way to know it was abandoned. Note: pool.query(...) used without .connect() doesn't leak this way, since it acquires and releases a client for you automatically — the leak is specific to code that manually calls pool.connect().
What happens next
If idleCount recovers between bursts and totalCount doesn't stay pinned at max, this may be genuine undersized capacity for a concurrency spike rather than a leak — see the connect-timeout playbook.
Guarantee release() runs on every exit path, including exceptions.
const client = await pool.connect();
try {
const result = await client.query("SELECT * FROM orders WHERE user_id = $1", [userId]);
return result.rows;
} finally {
client.release();
}What happens next
idleCount should fluctuate rather than stay pinned at 0, and waitingCount should stay near 0.
console.log({ total: pool.totalCount, idle: pool.idleCount, waiting: pool.waitingCount });Expected result
{ total: 10, idle: 6, waiting: 0 }What happens next
Pool usage no longer climbs unbounded under sustained traffic.
A single other place in the codebase that calls pool.connect() without a matching try/finally reproduces the exact same symptom. Search the whole codebase for pool.connect( rather than assuming the one fixed instance was the only one.
What would strengthen it: 6 more independent reproductions. Reproductions from 3 more distinct environments.