Database Connection Pool Sizing
Postgres wiki has been screaming this since 2012: connections = (core_count × 2) + effective_spindle_count. Your ORM default of 100 connections on an 8-core box with SSDs? Each connection beyond ~25 adds latency, not throughput. More connections ≠ more concurrency. The knee in the curve is measurable — and your connection pool is on the wrong side of it.
⚙️ Pool Configuration
Configure your database node hardware and workload profile. The engine computes the optimal pool size and provides guardrails for min/max bounds.
Why Connection Pool Size Matters
The single most common database performance mistake is setting the connection pool too high. Engineers assume more connections = more concurrency = more throughput, but the opposite is true: each connection consumes server memory (typically 2-10 MB for PostgreSQL, up to 4 MB for MySQL), and when the pool exceeds the database's ability to schedule work, context switching overhead destroys throughput. The PostgreSQL wiki explicitly recommends (core_count × 2) + effective_spindle_count as the starting formula.
The PostgreSQL Formula, Explained
For a server with 8 CPU cores and NVMe storage, the formula yields: (8 × 2) + 1 = 17 connections. With HDD storage, the effective spindle count is added — a 4-disk RAID 10 array contributes ~2 effective spindles, giving (8 × 2) + 2 = 18 connections. Many production outages trace back to connection pools set to 100 or 200, overwhelming the database with idle connections that consume memory and force the query planner to work harder.
Per-Application-Instance Sizing
When multiple application instances share a database, the total pool must be divided among them. With 4 application instances and an optimal pool of 20, each instance should use at most 5 connections. PgBouncer and ProxySQL are often deployed to multiplex application connections into a smaller database-facing pool — the tool output includes per-instance guidance for distributed deployments.