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

Short answer

Neither setting alone prevents exhaustion when long-running queries hold connections. Idle timeout only evicts connections that are idle in the pool; a connection executing a statement is "in use" and is not eligible for eviction, regardless of how long it runs. Maximum pool size merely raises the ceiling on concurrent sessions—it does not free anything. The reliable fix is to bound query duration (statement/query timeout) and size the pool to what the database can sustain.

1) Does idle timeout evict connections stuck in a long-running query?

No—this is expected behavior, not a bug, in DataGrip's 2023.2–2023.3 HikariCP-based pool (and HikariCP generally). Idle timeout applies only to connections sitting unused in the pool. A connection checked out and running SELECT pg_sleep(60) is "in use," so the pool cannot reclaim it until the statement finishes and the connection is returned. If many such queries pile up, the pool exhausts even with a 30 s idle timeout configured.

Verify it yourself:

1. Set Idle timeout to 30 s under Data Sources → Properties → Advanced → Connection pool.
2. In a console, run SELECT pg_sleep(60);
3. In a second console, run SELECT pid, state, query_start, query FROM pg_stat_activity WHERE datname = current_database(); — the sleeping session stays active well past 30 s.
4. After it completes, wait ~30 s and re-run the query; the session should drop to idle and then disappear.

2) Impact of raising maximum pool size from 10 to 30

Raising the cap does not create connections up front, but it permits up to 30 concurrent sessions. The cost scales roughly linearly with active connections:

• Database server: each session is a backend process/thread with its own memory (e.g., PostgreSQL's work_mem can apply per operation per session). 30 busy backends can triple memory/CPU pressure versus 10.
• File descriptors: each open connection is a socket on both ends. Check the client side with lsof -p <datagrip_pid> | grep -c TCP and the server side against max_connections.
• Hard limits: if 30 exceeds the database's max_connections headroom or the OS ulimit -n, new connections fail outright.

So a larger pool helps only if spikes are short-lived and the database has capacity; it makes exhaustion worse if the underlying cause is slow queries, because more sessions contend for the same server.

3) Workarounds for connections held by long-running statements

• Set a statement timeout so runaway queries release their connections: e.g., SET statement_timeout = '30s'; per session, or configure it on the database role/server. This is the most direct fix.
• Use DataGrip's query timeout/cancel options where available for the data source, and cancel long statements manually from the console.
• Keep the pool small (at or below sustainable DB load) so excess demand queues in the client rather than overwhelming the server.
• Moderate idle timeout (e.g., 5–10 min rather than 30 s) to trim genuinely idle connections without paying reconnection cost on every traffic burst.

Recommendation

For your symptom—exhaustion driven by long-running queries—tune in this order: (1) add a statement timeout, (2) keep max pool size near the default unless load testing proves the database handles more, (3) use idle timeout only to shrink the pool during quiet periods. One caveat: exact option names and any forced-eviction behavior may vary by DataGrip release, so confirm against your version's release notes before deploying changes.