Node.js Connection Pooling Under Production Load

Why pools exist

Opening a new database connection per request is expensive: TCP handshake, authentication, session setup. A pool keeps a set of warm connections and lends them to requests. Under load, pool behavior often matters more than micro-optimizations in JavaScript.

Why pools time out

A pool acquire timeout means your request waited too long for a free connection. Causes include slow queries holding connections, connection leaks, pool size too small for concurrency, or the database hitting max_connections. Fix the hold time first; raising pool size without fixing leaks only moves the outage to the database.

Connection leaks

Leaks happen when code acquires a connection and forgets to release it on error paths. Always release in finally. Prefer helpers that scope a connection or transaction for a single async function. Watch for long transactions and for request handlers that hold a connection while calling external HTTP APIs.

Sizing the pool

Rough guide: pool size per Node process should stay well under the database max_connections divided by the number of app instances. If each of 10 instances opens 20 connections, you need headroom above 200 on MySQL. Measure pool wait time and active connections under realistic load tests.

Node-side practices

• One shared pool per process — do not create a pool per request
• Set statement timeouts so runaway queries return connections
• Keep transactions short; do not await user input inside a transaction
• Log acquire wait duration as a first-class metric

Debugging checklist

When production times out: check slow query log, InnoDB history and locks, pool wait metrics, recent deploys, and whether error paths skip release. Reproduce with a load test that matches concurrency, not only average RPS.