ConnectionTimeoutException during concurrent request spikes in HikariCP

The Recommended Sizing Strategy

To prevent ConnectionTimeoutException without overwhelming the database server, avoid the instinct to simply increase maximum-pool-size to match your peak request thread count. Doing so often leads to database CPU contention and excessive context switching, which actually increases the time a connection is held, worsening the timeout problem.

The industry-standard starting point for sizing a HikariCP pool is based on the database server's hardware capacity rather than the application's request volume:

connections = ((core_count * 2) + effective_spindle_count)

Where core_count is the number of CPU cores on the database server and effective_spindle_count represents the number of disks in a RAID array (or a similar factor for SSD throughput). This formula ensures the database can actually process the concurrent queries without spending more time managing threads than executing SQL.

Addressing Dynamic Scaling

HikariCP does not natively support dynamic scaling of the maximum-pool-size based on system resources. The pool size is intended to be a static ceiling to protect the database from crashing under load. If you require a pool that adjusts to available resources, you must implement an external management layer using JMX (Java Management Extensions) to programmatically update the pool configuration at runtime.

Implementation Steps for Mitigation

1. Calculate the Baseline: Apply the formula above to determine a sustainable maximum-pool-size.
2. Align Database Limits: Ensure the database server's own max_connections setting is higher than the sum of all maximum-pool-size values across all application instances.
3. Optimize Connection Timeout: Set connection-timeout to a value that fails fast (e.g., 5000ms to 30000ms) to prevent request threads from piling up and exhausting application memory.
4. Monitor Metrics: Use Micrometer or JMX to track ActiveConnections and PendingThreads. If PendingThreads is consistently high while ActiveConnections is at the limit, you have a genuine bottleneck.

Verification and Diagnostics

To verify if the bottleneck is the pool size or the database performance, compare these two indicators during a spike:

• Pool Exhaustion: Application logs show ConnectionTimeoutException, but the database server shows low CPU usage and few active sessions.
• Database Saturation: Application logs show timeouts, and the database server shows 100% CPU usage or "Too many connections" errors.

Missing Diagnostic Detail: Are you using a synchronous blocking architecture (Standard Spring MVC) or a non-blocking architecture (Spring WebFlux)? The recommendation for pool sizing differs significantly if the application is not tying one request thread to one database connection.