connection-pool-sizinglisted

# Connection Pool Sizing ## Purpose Size a database pool from measurement and distinguish insufficient local capacity from database saturation, leaks and long-held connections. Raising `maximumPoolSize` helps only if measured database headroom can absorb the extra concurrent work within the required SLO. ## Workflow Before applying settings, inspect compiler/runtime, resolved HikariCP, Spring Boot, Hibernate and JDBC driver versions, database engine/version, metrics binding and transaction/connection release mode. No single Java baseline is declared for this diagnostic workflow; the SQL examples target PostgreSQL, and virtual-thread APIs require Java 21+. Preserve target versions. Missing workload or capacity evidence requires a measurement plan and conditional recommendation, not an invented size. 1. **Measure `W`**, the mean connection **hold** time, with `hikaricp.connections.usage`; inspect p50/p99 separately for tails. Hold time runs from successful checkout until return to the pool, which can include time before the first statement and after commit. Verify the metric adapter; completed-use samples can omit connections still stuck or leaked. 2. **Compute mean concurrency `L = λ_borrow × mean(W)`** using completed borrows/second and hold durations from the same pool and stable interval, not query rate or a percentile. Then model a candidate pool against the arrival distribution and latency/error budget. A fixed 1.5× margin is a starting hypothesis,