Understanding HikariCP Connection Pool Sizing: Principles, Experiments, and Practical Guidelines

The author shares a translation of a HikariCP wiki article that clarifies common misconceptions about database connection pool sizing and presents practical guidance.

Using a benchmark video from Oracle Real World Performance Group, the author shows that a 2048‑connection pool under a 9600‑thread load incurs significant wait times, while reducing the pool to 1024 and then to 96 connections dramatically lowers wait events and improves throughput, even shortening response times from around 100 ms to 3 ms.

The improvement is explained by basic computer science principles: when the number of threads exceeds the number of CPU cores, context‑switching overhead increases, and excessive connections cause contention for limited resources such as CPU, disk, and network.

Disk I/O, especially on spinning disks, introduces seek and rotation delays; SSDs reduce these delays, meaning fewer threads are needed to keep the CPU busy. Network latency behaves similarly.

Based on these observations, the author presents a simple formula (originally from PostgreSQL) to estimate a suitable pool size: Connection count = ((core count * 2) + effective disk count) . For a 4‑core i7 server with one effective disk, the recommended pool size is about 9–10 connections.

The article emphasizes that a small pool combined with a queue of waiting threads often yields the best performance, and warns against naïvely matching the pool size to the number of concurrent users.

Additional notes advise tailoring pool sizes to specific workloads, such as separating long‑running and short‑running transactions into different pools, and aligning the pool size with the maximum number of concurrent tasks a system can safely execute.