How to Implement Database Connection Pooling in Node.js

Establishing a new database connection for every incoming HTTP request is extremely slow and resource intensive. A database connection involves network handshakes, authentication, and memory allocation that can take tens to hundreds of milliseconds. A connection pool maintains a set of pre-established connections that are reused across requests, eliminating this overhead and dramatically improving throughput.

A pool creates a fixed number of database connections when the application starts and keeps them open. When your application needs to query the database, it checks out an available connection from the pool, executes the query, and returns the connection to the pool when done. If all connections are checked out, new requests wait in a queue until one becomes available.

A common mistake is setting the pool size too high. More connections do not mean better performance. Each database connection consumes memory and resources on both the application server and the database server. A good starting point is a pool size equal to the number of CPU cores on your database server multiplied by two. Profile under realistic load and adjust based on actual measurements.

When you call mongoose.connect, pass an options object with the maxPoolSize property. Mongoose manages the pool internally and reuses connections from it for all model operations. Also configure connectTimeoutMS to set how long to wait for a connection to be established, serverSelectionTimeoutMS for how long to try connecting before giving up, and socketTimeoutMS for how long an idle socket stays open.

When using the pg package for PostgreSQL, instantiate a Pool object instead of a Client. Pass configuration including max for the maximum pool size, idleTimeoutMillis to close connections that have been idle longer than this duration, and connectionTimeoutMillis to reject requests that wait too long for a connection. Call pool.query directly instead of managing individual client checkouts for simple queries.

If your application receives more concurrent requests than the pool has connections, requests queue up waiting for a connection. If the wait exceeds the connection timeout, the request fails with an error. Monitor the pool utilization with metrics. If you frequently see pool exhaustion, either increase the pool size, optimize slow queries that hold connections longer, or scale horizontally by adding more application instances.

When using low-level database clients that require manual connection management, always release connections back to the pool after use. Wrap queries in try-finally blocks to ensure the connection is released even if the query throws an error. Failing to release connections causes pool exhaustion over time even when the application has low traffic, eventually making all new requests fail.

Collect and expose metrics about your connection pool including the total size, number of idle connections, number of active connections, and the queue length of waiting requests. Expose these as metrics in your application's monitoring system. Set alerts when the queue length stays non-zero for extended periods or when the number of active connections stays at the maximum pool size, as these indicate you are approaching or at capacity.