Understanding Database Connection Pool Sizing: Lessons from HikariCP and Real‑World Performance Tests

The author translates a HikariCP wiki article that dispels common misconceptions about database connection‑pool configuration and shares practical insights.

When a web service expects around 10,000 concurrent users (≈20,000 TPS), the correct question is not "how large should the pool be?" but "how small should it be?".

A benchmark video from Oracle Real World Performance Group shows 9,600 concurrent threads performing database operations with a 550 ms sleep between accesses. With an initial middleware pool of 2,048 connections, each request waited 33 ms in the pool queue and 77 ms to execute SQL, while the database CPU was at ~95 %.

Reducing the pool to 1,024 connections kept throughput similar but cut wait events in half; further shrinking to 96 connections lowered average queue wait to 1 ms and SQL execution to 2 ms, dropping overall response time from ~100 ms to 3 ms.

The improvement stems from fundamental computer‑science principles: a CPU core can execute only one thread at a time, and excessive threads cause context‑switch overhead. Thus, thread counts should not vastly exceed core counts.

Performance bottlenecks fall into three categories—CPU, disk, and network. Disk I/O, especially on spinning disks, introduces seek and rotational latency; SSDs eliminate these latencies, reducing blocking and allowing fewer threads to achieve higher performance. Network latency behaves similarly.

A widely applicable sizing formula (originating from PostgreSQL) is:

((CPU_cores * 2) + effective_disk_count)

For a 4‑core i7 server, this yields ((4 * 2) + 1) = 9 , rounded to about 10 connections. Hyper‑threading cores should not be counted.

Practical advice: use a small connection pool (e.g., 2 × CPU cores) and let the remaining business threads wait in a queue. Avoid oversized pools such as 1,000 connections for a handful of concurrent users. In mixed workloads, consider separate pools for long‑running and short‑running transactions, and align pool size with the number of concurrent tasks rather than the opposite.