Maximum Pool Size vs. Idle Timeout: Which Limits Reduce Connection Pool Exhaustion in DataGrip?

DataGrip’s built‑in HikariCP connection pool can occasionally hit exhaustion when traffic surges or long‑running queries keep connections marked as “in use.” The UI exposes two key levers: Maximum pool size and Idle timeout, each documented under Data Sources → Properties → Advanced → Connection pool.

The goal is to determine which configuration change most reliably prevents spikes in active connections while respecting database and OS limits. Increasing Maximum pool size from the default 10 to 30 allows more concurrent sessions but may overwhelm the database or exhaust file descriptors. Conversely, a short Idle timeout (e.g., 30 s) aggressively frees unused connections, keeping the pool lean, yet can trigger reconnection overhead during brief traffic bursts.

Uncertainty remains around the documented behavior: in versions 2023.2‑2023.3, the pool does not always honor the idle timeout when a connection is flagged as “in use” by a long‑running statement (such as a 60‑second SELECT pg_sleep). This can lead to intermittent exhaustion even when limits appear respected.

1) Does DataGrip’s idle timeout correctly evict connections that are idle but still marked as in use by a long‑running query?
2) What measurable impact does raising the maximum pool size from 10 to 30 have on the database server’s resource utilization and OS file‑descriptor count?
3) Are there documented workarounds or additional settings that force eviction of such connections during long‑running statements?