06.02 · Concept
Databases Under Load
Apply Little's Law to a connection pool and explain why the pool, not the query, is usually the bottleneck.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Little's Law turns database pool sizing into capacity maths: throughput depends on how many connections can be busy and how long each request holds one. Slow SQL is not required for saturation. A short query inside a long transaction can still exhaust the pool and push latency into the queue.
What this lesson answers
- how to size a database connection pool
- why fast queries still cause request latency
- how Little's Law applies to database connections
Notes
Little's Law for Database Connection Pools — Little's Law exists to relate concurrency, throughput, and latency so teams can predict when a finite database connection pool saturates; without it, requests pile up in the pool queue even when individual SQL queries look fast.
Key Concepts: - Little's Law is , where is average in-flight work, is throughput in requests/second, and is average time in the system in seconds. - For a connection pool, required pool size is approximately ; at QPS and $50ms =…
References
Common questions
- Why can an API be slow when database queries are fast?
- The request may be waiting for a connection before the query starts. Query timing usually measures execution after checkout, not time spent queued behind other requests. If each request holds a connection while doing application work, transactions, Redis calls or HTTP calls, the pool can saturate even while the database itself looks healthy.
- How do I use Little's Law for a connection pool?
- Use the relationship between concurrency, throughput and time in system. For a pool, the useful approximation is that needed connections equals request rate multiplied by connection hold time. Hold time means the whole period between checkout and return, not just SQL execution. That is the number that determines pool pressure.
- Should I increase pool size during a database incident?
- Not blindly. Larger pools across many app instances can create a connection storm and exhaust the database connection limit. If the real issue is long hold time or too many instances, raising every pool may make recovery harder. Check pending, active and wait metrics before changing pool limits.
Short definition: what is Databases Under Load?