Database Connection Pool Sizing - Demystified!
summary
Claims that bigger pools always help are false: using Little's Law the example shows 50 tps at 100 ms needs ~5 connections, not hundreds, while a misconfigured setup opens 8 JVMs × 80 = 640 connections against a 104‑core server that can handle ~2×104+spindles = 216 max. Applying Kingman's law explains why pushing utilization above ~75–80% explodes wait times. Practical rule: size pools by cores (≈2×cores+spindle), split short/long workloads, and prefer HikariCP defaults unless you measure otherwise.
AI-written summary · about
chapters (11)
- 0:00Connection pool sizing
- 1:18Why config matters
- 5:56How pools work and benefits
- 9:30Requests exceed connections
- 12:22Little’s Law for pools
- 15:55Minimal pool size limits
- 18:00Kingman’s Law limits
- 21:36Max pool size by core ratio
- 24:04Pool sizing miscalculation example
- 28:55Key takeaways
- 30:21Q&A troubleshooting
related talks
30mLeverage connection pooling and multiplexing for performance and scalability
20mElephant by the pool: PostgreSQL connection poolers overview
50mREX: HikariCP Optimizations in Java/Spring Boot/OpenShift
13mA Deep Dive into the DB Connection Pool
27mThe world's worst pool party: Connection management with Prisma
48mHow to Use the new JDBC 4.3 Sharding API for Massive OLTP Scaling
51mWhen ORM Becomes OMG: Performance Pitfalls in JPA and Friends
45mWhen ORM Becomes OMG: Performance Pitfalls in JPA and Friends