Quarkus 3.8 Datasource max-lifetime shift and its impact on connection pool exhaustion

When upgrading a Quarkus application from version 3.7 to 3.8, the default quarkus.datasource.jdbc.max-lifetime changes from being unset (relying on HikariCP’s internal default) to a fixed 30‑minute value, while quarkus.datasource.jdbc.idle-timeout defaults to 10 minutes. This shift alters when idle connections are evicted and can change the appearance of connection pool exhaustion under workloads that hold connections idle for periods between the two thresholds.

Because the new defaults also expose the leak-detection-threshold property only in 3.8, teams must decide whether to rely on the built‑in eviction, explicitly configure leak detection, or adjust the timeouts to match their database’s wait‑timeout and typical connection usage. The interaction between these settings and the database’s own connection‑close behavior is not fully documented for the upgrade path, leaving uncertainty about the safest configuration.

What is the effective idle‑connection eviction behavior in Quarkus 3.8 when both quarkus.datasource.jdbc.max-lifetime and quarkus.datasource.jdbc.idle-timeout are left at their defaults?

Should quarkus.datasource.jdbc.leak-detection-threshold be enabled to detect leaked connections that could masquerade as pool exhaustion?

Is it necessary to adjust quarkus.datasource.jdbc.max-lifetime or enable validation‑on‑borrow to prevent stale connections after the database closes idle connections?