HikariCP Connection Pool

Tuning the connection pool

maximumPoolSize

The ceiling on database connections. HikariCP holds this many connections open under load. The right value is determined by your database's max_connections, query latency, and concurrency — not by thread count. A common starting formula: connections = (cores × 2) + effective_spindle_count. More is not always better.

connectionTimeout

How long a thread waits to acquire a connection before throwing SQLTransientConnectionException. This is your request latency ceiling under pool exhaustion. Set too low and you get cascading failures under brief spikes. Set too high and your HTTP request hangs. 3–5 seconds is typical.

Queue buildup

When all connections are active, arriving requests queue in HikariCP's internal wait queue. Watch the amber bar grow — this is your first signal that the pool is undersized for current load. If the queue drains between bursts, the pool is correctly sized. If it grows monotonically, you need more connections or faster queries.

minimumIdle

Connections kept open when idle. Eliminates connection setup latency on the first request after quiet periods. Setting it equal to maximumPoolSize gives a fixed-size pool — recommended for consistent server workloads to avoid the overhead of pool resizing.

maxLifetime

Maximum age of a connection before HikariCP retires and replaces it. Must be shorter than any network or database-side connection timeout. The default 30 minutes handles most database configurations but check your RDS or PostgreSQL idle connection settings.

Leak detection

Set leakDetectionThreshold to log a stack trace when a connection is held longer than expected. Invaluable for finding code paths that forget to close connections or hold them across slow external calls. Start at 2× your 99th-percentile query latency.