Database connection pooling is a foundational technique for managing reusable database connections to minimize the overhead of establishing new connections for each request. Instead of creating and destroying connections repeatedly, a connection pool maintains a cache of open connections that applications borrow and return, dramatically improving throughput and reducing latency. The key challenge lies not in whether to pool connections, but in tuning pool size, timeouts, and validation strategies to match your workload—oversized pools waste memory and database resources, while undersized pools create bottlenecks and timeouts. Understanding connection lifecycle states (idle, active, borrowed, evicted) and the trade-offs between different pooling modes (session, transaction, statement) enables you to build resilient systems that gracefully handle connection failures, scale efficiently, and avoid the silent killer: connection pool exhaustion.
What This Cheat Sheet Covers
This topic spans 12 focused tables and 120 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Pool Size Configuration Strategies
| Strategy | Example | Description |
|---|---|---|
maxPoolSize=10minPoolSize=10 | • Sets both minimum and maximum to same value • HikariCP recommends fixed pools for consistent performance and simpler behavior • eliminates pool resizing overhead | |
minIdle=5maxTotal=20 | • Pool grows and shrinks between min and max based on demand • trades predictability for potential resource savings when load is variable | |
\text{pool size} = (\text{cores} \times 2) + \text{spindles} | • Classic sizing formula for CPU-bound workloads with disk I/O • for 4-core system with 1 disk → pool size of 9-10 connections is typically optimal | |
Start small (5-10), monitor wait times, increment | • Measure, don't guess: start with minimal pool size, monitor connection acquisition latency, increase only when wait times exceed acceptable threshold • prevents over-provisioning | |
maxPoolSize=1 per Lambda | • Serverless functions should use pool size of 1 or rely on external poolers (pgBouncer, RDS Proxy) • each function instance creates its own pool, multiplying connection count rapidly |