HikariCP pool sizing in Grails 4+: fixed minimumIdle floor versus idle shrink for low-traffic workloads

Choosing Between Fixed and Dynamic Pools

For low-traffic Grails applications, a small fixed-size pool (where minimumIdle equals maximumPoolSize) is generally the superior choice. This configuration eliminates connection churn and prevents the latency spikes associated with TCP/TLS handshakes during the first request after an idle period.

The Trade-off Analysis

The decision rests on whether the primary cost constraint is database session overhead or request latency:

• Fixed Pool: Maintains a constant number of connections. This is ideal when the database can comfortably handle a few idle sessions per application instance. It ensures predictable performance for sporadic users.
• Dynamic Pool: Allows the pool to shrink to minimumIdle after the idleTimeout expires. This is only recommended if the database has extremely strict session limits or if you are running hundreds of small micro-instances where aggregate idle connections would exhaust database resources.

Implementation in application.yml

In Grails 4 and later, these settings are passed to HikariCP via the dataSource.properties map. To implement a stable, low-overhead fixed pool, use the following pattern:

dataSource:
  properties:
    maximumPoolSize: 5
    minimumIdle: 5
    idleTimeout: 600000
    maxLifetime: 1800000

Technical Considerations and Verification

Because Grails versions inherit different Spring Boot and HikariCP releases, verify the actual resolved configuration using these steps:

1. Startup Logs: Check the application logs during boot; HikariCP typically prints the configured pool size and timeouts.
2. Session Monitoring: Query your database's process list (e.g., SHOW PROCESSLIST in MySQL) during an idle period to confirm the connection count matches your minimumIdle.
3. Timeout Alignment: Ensure that the database's own connection timeout (e.g., wait_timeout) is longer than HikariCP's maxLifetime to avoid "connection closed by peer" errors.

Note: If you are using a cloud-managed database with aggressive connection killing, a dynamic pool may actually increase error rates unless keepaliveTime is also configured.