Database Connection Pool Size Calculator

It originates from the HikariCP connection pool project, authored by Brett Wooldridge, and is grounded in queuing theory (Little's Law). The '×2' accounts for the fact that while one thread is executing CPU work, another can be waiting on I/O — keeping both the CPU pipeline and the I/O channel saturated simultaneously. The spindle term adds one slot per independent HDD read/write head, since those can serve requests in true parallel.

PostgreSQL ships with max_connections = 100 by default (configurable in postgresql.conf). This is a hard server-wide ceiling across ALL clients. Your application pool must stay well below this; a common guideline is to reserve at least 3 connections for superuser/admin tasks and split the remainder across all application services. For example, with 2 apps and max_connections = 100, each app's pool should cap at roughly (100 − 3) / 2 ≈ 48 connections maximum.

Use the vCPU count reported by your OS (nproc on Linux), but be aware that on hyper-threaded hardware, two vCPUs share one physical core's execution units. For burstable cloud instances (AWS t3, t4g), apply the low or medium load modifier. For dedicated bare-metal or compute-optimized instances (c5, c6, m6) where vCPU ≈ physical thread, use the formula directly without discounting.

Connection poolers (PgBouncer in transaction mode, ProxySQL) multiplex many app-side connections onto fewer server-side connections. When a pooler is present, you can reduce your app-side pool to roughly cores × 1 because the pooler serializes the handoff. The pooler itself should be configured with a server_pool_size matching the HikariCP formula. Double-layered pools without this adjustment waste RAM and add unnecessary round-trip latency.

Oversized pools cause: (1) increased memory consumption — PostgreSQL allocates ~5–10 MB of shared memory per backend process; (2) CPU context-switching overhead as the OS scheduler juggles hundreds of idle threads; (3) lock and semaphore contention inside the database itself. The HikariCP documentation notes that going from 10,000 to 10,000+ connections on a benchmark system decreased throughput by 50% compared to a correctly sized small pool.

Yes — each distinct database endpoint (primary, read replica, shard) should have its own pool sized independently using the formula against the core count of that server. A 4-core read replica should get an 8-connection pool regardless of how large the primary's pool is. Application-level routers (e.g., AWS RDS Proxy, Vitess) may further adjust these numbers based on their own internal multiplexing.

Partially. MongoDB's official driver documentation recommends a pool size between 50–100 for most workloads, though its internal WiredTiger storage engine also benefits from CPU-aligned tuning. Redis is single-threaded (pre-Redis 6) or uses I/O threads (Redis 6+), so connection pooling is less CPU-sensitive; a pool of 10–20 connections per app instance is typically sufficient regardless of core count. The HikariCP formula is most rigorously applicable to SQL databases with process-per-connection backends (PostgreSQL) or thread-per-connection backends (MySQL).

Monitor these metrics: (1) Pool wait time — if threads wait >1 ms on average to acquire a connection, the pool is too small. (2) Idle connections — if >30% of connections are idle at peak, the pool may be oversized. (3) In PostgreSQL, run SELECT count(*), state FROM pg_stat_activity GROUP BY state; to see active vs. idle connections in real time. HikariCP exposes JMX/Micrometer metrics (hikaricp.connections.pending, hikaricp.connections.active) that integrate directly with Prometheus/Grafana dashboards.