The 30 second answer
I check the pool metrics first: pending threads and connection acquire time. If threads wait for connections, I look for long transactions holding them, like slow queries or remote HTTP calls inside a transaction. A bigger pool is rarely the fix, because small pools usually perform better. I set a connection timeout so callers fail fast and enable leak detection to log connections held too long.
Check Hikari metrics: pending threads and connection acquire time. If threads wait for connections, look for long transactions holding them: slow queries, or remote HTTP calls made inside a transaction. A bigger pool is rarely the fix; HikariCP's sizing guide says a small pool, starting near (core_count * 2) + effective_spindle_count, usually beats a big one. Set connectionTimeout so callers fail fast, and leakDetectionThreshold to log connections held too long. Follow-up: Why can a bigger pool make it worse? (More concurrent queries compete for the same CPU and disk on the DB.)