Database Connection Pool Sizer

The tool uses the HikariCP formula popularised by the article 'About Pool Sizing': pool_size = (core_count × 2) + effective_spindle_count. For SSDs, effective_spindle_count = 1. This formula is a starting point — workloads with very long queries or high I/O wait may need more connections, while CPU-bound workloads need fewer.

Each database connection consumes memory on both the application server and the database server (PostgreSQL uses ~5–10 MB per backend process). Beyond a certain point, more connections cause context-switching overhead and lock contention that slows everything down. The formula is designed to keep the database busy without overwhelming it.

The min pool size is the number of connections kept open at idle — keeping some warm connections avoids connection establishment latency on request spikes. The max pool size is the hard ceiling — requests that arrive when all connections are busy wait in a queue (with a timeout). Setting min = max (fixed pool) is common in high-traffic production environments to avoid connection churn.

Each application instance maintains its own connection pool independently. If you have 3 instances each with a max pool of 10, your database receives up to 30 simultaneous connections. Always compute total_connections = max_pool × instances and verify this is below your database's max_connections setting.

PostgreSQL defaults to max_connections = 100 (some managed providers set 500 or more). Exceeding this causes new connection attempts to fail with 'too many connections'. For high-concurrency workloads, use PgBouncer or pgpool-II as a connection proxy — your app connects to PgBouncer, which maintains a smaller number of real connections to PostgreSQL.

Redis is single-threaded and processes commands sequentially, so a large pool does not parallelise Redis operations. A small pool (5–20) is usually sufficient. For Cluster mode, maintain a separate pool per shard. Redis clients like ioredis and redis-py handle pooling automatically.