HikariCP Connection Pool Configuration and Tuning
Fast recall
Quick revision
Core answer
spring.datasource.hikari.*. The critical properties are `maximum-pool-size` (cap on total connections), `minimum-idle` (idle connections kept ready), `connection-timeout` (how long your code waits for a free connection before throwing SQLTransientConnectionException), `idle-timeout` (retire idle connections after this duration), and `max-lifetime` (force-retire any connection older than this — must be less than the DB's wait_timeout). The most frequent production bug is confusing connection-timeout (pool acquisition) with JDBC queryTimeout (SQL execution) — they are unrelated. Monitor the pool with Actuator metrics hikaricp.connections.active, hikaricp.connections.pending, and hikaricp.connections.timeout to detect saturation before it becomes an outage.Whether you can distinguish different timeout types, size a pool intentionally, and know that Hikari is the default
Confusing pool connection-timeout with JDBC query-timeout; setting pool-size very high thinking it's better; not knowing `max-lifetime` must be less than DB wait_timeout
Mention `leakDetectionThreshold` for finding connections that aren't returned to the pool, and explain why HikariCP uses a lock-free design with `ConcurrentBag` for connection state
Interview-ready guide
Interview answer
HikariCP is Spring Boot's default connection pool — you configure it under the spring.datasource.hikari.* prefix.
The properties I actually tune are `maximum-pool-size`, `minimum-idle`, `connection-timeout`, `idle-timeout`, and `max-lifetime`.
The single most important distinction is what each timeout actually means. `connection-timeout` controls how long your code waits for a connection from the pool before throwing SQLTransientConnectionException. It is not a query timeout — that's a separate JDBC setting on the Statement. Candidates often conflate these.
The other operational rule: `max-lifetime` must be less than the database's idle-connection timeout. If MySQL closes connections after 8 hours and Hikari holds them for 9 hours, under low traffic you'll get intermittent Connection is closed errors that are maddening to reproduce.
For pool sizing, I use the HikariCP author's rule — (cores × 2) + spindle_count, so typically 10-20 per app instance. Bigger pools don't help because the database becomes the bottleneck through context-switching overhead.
Two more production details:
`leak-detection-threshold=60000` in staging logs a stack trace whenever a connection isn't returned within 60 seconds. It's saved me many times from forgotten close() calls in legacy code.
Monitoring through Actuator metrics — hikaricp.connections.pending should almost always be zero. If it's non-zero for sustained periods, the pool is saturated and your app is about to start failing.
Why HikariCP won: it's lock-free via a custom ConcurrentBag data structure — no synchronized blocks — so throughput scales with cores in a way Tomcat JDBC and DBCP2 never could.
HikariCP Connection Pool Configuration and Tuning
Direct Answer
Configure HikariCP via spring.datasource.hikari.*. The critical properties are maximum-pool-size (cap on total connections), minimum-idle (idle connections kept ready), connection-timeout (how long your code waits for a free connection before throwing SQLTransientConnectionException), idle-timeout (retire idle connections after this duration), and max-lifetime (force-retire any connection older than this — must be less than the DB's wait_timeout). The most frequent production bug is confusing connection-timeout (pool acquisition) with JDBC queryTimeout (SQL execution) — they are unrelated. Monitor the pool with Actuator metrics hikaricp.connections.active, hikaricp.connections.pending, and hikaricp.connections.timeout to detect saturation before it becomes an outage.
Common Mistakes & Pitfalls
Confusing pool connection-timeout with JDBC query-timeout; setting pool-size very high thinking it's better; not knowing max-lifetime must be less than DB wait_timeout
Check your understanding
Answer these without looking back at the article.
- How would you diagnose a `SQLTransientConnectionException: Could not connect to pool` error?
- What is `ConcurrentBag` and why is it faster than a synchronized queue?
- When should you disable `connection-test-query`?
- How do you tune HikariCP differently for a read replica vs primary?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.