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

Grails 4 and later default to HikariCP for GORM data sources, so low-traffic cost tuning is configured through dataSource.properties.* keys in application.yml rather than legacy Tomcat pool settings. The goal is to reduce database connection or session costs for a workload that sits idle for extended periods.

HikariCP interprets minimumIdle as a floor and maximumPoolSize as a ceiling. When both are set to the same low value, the pool remains fixed and does not release idle connections during quiet periods. Alternatively, setting minimumIdle below maximumPoolSize with a short idleTimeout allows the pool to shrink, though this can introduce connection churn and latency spikes on the first request after an idle gap. Because Grails 4, 5, and later inherit different Spring Boot and HikariCP versions, effective defaults and supported property names are version-sensitive and depend on the specific release in use.

The unresolved decision is whether to cap cost with a small fixed pool or accept extra acquisition latency after idle periods in exchange for surrendering idle connections. Which configuration boundary is appropriate for a low-traffic Grails application, and how should the trade-off be evaluated when the active implementation and resolved defaults differ across Grails versions?