IntelliJ Database Connection Pool Size Change in 2026.1: Unresolved Idle-Connection Eviction Policy

Answer to the specific questions

Based on the current implementation of IntelliJ IDEA 2026.1 Database tool (which uses HikariCP as its JDBC pool):

1. Should IntelliJ introduce a configurable idle‑timeout or automatic eviction policy? Likely explanation: The pool is created with HikariCP’s default idleTimeout of 600 000 ms (10 min) but IntelliJ sets minimumIdle = maximumPoolSize (both equal to the UI‑configured pool size). When minimumIdle equals maximumPoolSize, HikariCP disables idle‑connection eviction, so connections stay alive until the IDE shuts down. This is a confirmed fact from the pool‑creation logs. Adding a user‑editable idle‑timeout (or allowing minimumIdle < maximumPoolSize) would give developers control over eviction.
2. What mechanisms can developers use to monitor active pool usage in the absence of a built‑in UI? Confirmed facts:
   • Enable HikariCP debug logging by placing a log4j2.xml in ~/.config/JetBrains/IntelliJIdea2026.1/log/ with:

     <Logger name='com.zaxxer.hikari' level='DEBUG'/>

     Then check idea.log (Help → Show Log in Explorer/Finder) for lines like HikariPool-1 - Pool stats (total=10, active=5, idle=5, awaiting=0).
   • Query the database directly for session counts, e.g. for PostgreSQL:

     SELECT count(*) FROM pg_stat_activity WHERE datname = current_database();

     Similar views exist for MySQL (SHOW PROCESSLIST;), Oracle (SELECT COUNT(*) FROM v$session;), etc. Run the query before and after opening/closing consoles to see the change.
   Likely explanation: These are the only reliable ways to observe pool usage because IntelliJ does not expose a UI metric.
3. Does the pool size setting apply globally across all database consoles for a data source, or is it isolated per console? Confirmed fact: The pool is created per data source definition. All consoles, SQL files, and attached sessions that reference the same data source share a single HikariCP instance inside the IDE process. Therefore the pool size is global for that data source, not per console.

Steps to diagnose and prevent intermittent exhaustion

1. Verify the current pool size and idle behavior:
   • Open Help → Show Log in Explorer/Finder, locate idea.log, search for HikariPool at startup. You should see lines such as HikariPool-1 - Added connection conn0: url=jdbc:postgresql://… and HikariPool-1 - Pool stats (total=30, active=0, idle=30).
2. If you have access to the database server, run a session‑count query (see above) while opening several consoles to confirm that the number of backend connections matches the configured pool size.
3. To reduce the risk of exhaustion:
   • Lower the pool size via File → Settings → Database → Data Sources → Advanced (e.g., to 10‑15) for long‑running projects.
   • Manually return consoles to the pool using the red square “Disconnect” toolbar button in the Database tool window when a console is idle for an extended period.
   • If you can modify the IDE launch configuration, add a VM option to override HikariCP’s idle timeout, e.g.: -Dhikaricp.idleTimeout=300000 (5 min). This only works if IntelliJ does not force minimumIdle = maximumPoolSize; otherwise you must also adjust minimumIdle via an undocumented property or request the feature from JetBrains.
4. If you cannot run database‑side queries (no permission or no access), rely solely on the HikariCP debug logs as described in step 1. In that case, the recommendation is to lower the pool size and manually disconnect consoles, because you cannot verify pool usage externally.

Missing diagnostic detail that would change the recommendation

Do you have permission to execute queries like pg_stat_activity, SHOW PROCESSLIST, or equivalent on the target database? If the answer is “no”, external monitoring is not possible and you must depend on IDE logs and manual pool‑size adjustment. If the answer is “yes”, you can use the database‑side queries to confirm pool exhaustion and tune the size more precisely.