What is the HikariCP formula?

pool_size = (core_count × 2) + effective_spindle_count. For SSDs or NVMe drives use spindle_count = 1. For spinning-disk arrays use the actual number of physical spindles. This formula calculates the total concurrent connection capacity the database hardware can execute efficiently.

What is Little's Law?

Little's Law states L = λ × W, where L is the average number of items in the system, λ is the average arrival rate, and W is the average time spent in the system. Here L = required concurrent query connections, λ = peak concurrent requests/sec, and W = average query duration in seconds.

Why not just set the pool size to a very large number?

Each idle connection consumes memory on both the application server and the database. Excess connections also increase context-switching overhead and can degrade throughput rather than improve it.

Should I use the HikariCP result or the Little's Law result?

The HikariCP formula represents the database hardware throughput ceiling, while Little's Law estimates workload concurrency demand. Do not exceed the hardware ceiling; if Little's Law demand is higher, let requests queue in the connection pool or scale up database cores.

Do I need to multiply by the number of app servers?

No. The HikariCP formula yields the total connection capacity for the database server. That total must be partitioned across your app instances (or fronted by a connection pooler like PgBouncer) so the sum of all instance pools does not exceed hardware capacity.

Connection Pool Sizing Calculator

Calculate the optimal database connection pool size using the HikariCP formula and Little's Law analysis.

HikariCP Formula Inputs

CPU Core Count

Physical or virtual cores available to the database server.

Effective Spindle Count

Use 1 for SSD / NVMe. Use the number of physical spinning disks for HDD arrays.

Little's Law Inputs (optional)

Peak Request Rate (req/s)

Peak throughput of queries or requests reaching the database each second.

Average Query Duration (ms)

Mean time a single query occupies a connection, in milliseconds.

Deployment Scale

Number of App Instances

How many application server instances share the database.

HikariCP Hardware Ceiling

total DB capacity = (cores × 2) + spindles

—

Little's Law Workload Demand

L = concurrency × (query_ms / 1000)

—

Enter Peak Request Rate and Average Query Duration to enable.

Config Snippets

Copied!

Summary

Determines the right number of database connections for your application using two complementary methods: the HikariCP formula (core_count × 2 + effective_spindle_count) for database hardware capacity partitioned across app instances, and Little's Law (L = λ × W) for concurrency demand. Avoid context switching and connection storms while keeping pools properly sized.

How it works

Enter your database server's CPU core count and storage spindle count (use 1 for SSD or NVMe).
Optionally add Little's Law inputs: peak concurrent requests per second and average query duration.
The tool calculates total DB hardware capacity via HikariCP (cores × 2 + spindles) and allocates it across app instances.
Compare against Little's Law concurrency demand without exceeding the hardware ceiling; excess queries queue safely.

Use cases

Sizing a HikariCP pool for a Spring Boot or Java service.
Tuning PostgreSQL max_connections alongside PgBouncer pool size.
Estimating connection requirements before a production launch.
Diagnosing connection exhaustion or idle-connection waste.
Capacity planning when scaling from one to multiple app servers.

Frequently Asked Questions

Last updated: 2026-05-23 · Reviewed by Nham Vu