Database Connection Pool Sizer
A mathematically precise utility for calculating the maximum safe connection pool size per pod. It prevents connection exhaustion and database brownouts during aggressive horizontal scaling.
Who this Lab is for
Designed for
- Backend and platform engineers
- Database administrators
- SRE teams reviewing autoscaling rules
Use it when
- Configuring Prisma, HikariCP, or PgBouncer pool limits
- Setting up a new horizontally scaling service
- Investigating connection exhaustion incidents
A complete run, step by step
Define database capacity
Enter the absolute maximum connections your database or proxy allows.
Set autoscaler bounds
Supply the maximum replica count your HPA will scale the service to.
Account for reserved connections
Exclude connections required for migrations, superusers, and sidecars.
Review unallocated buffer
Examine the remaining unallocated connections as a safety buffer for sudden spikes.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Database max_connections
The absolute maximum connections the database cluster or proxy can accept.
Maximum pods
The highest number of application pods that the HPA will scale out to.
Reserved connections
Connections reserved for migrations, superusers, or other services.
What the result tells you
Your report includes
- Maximum safe connections per pod
- Optimal database configuration bounds
- Risk analysis for autoscaling limits
How it is determined
The calculator subtracts reserved connections from the database limit, then divides the remainder by the maximum pod count. The result is floored to ensure that even at maximum scale, the database connection limit is never breached.
Calculates an exact mathematical floor bound based on standard Postgres/MySQL connection scaling logic to prevent connection drops at peak scale.
Model assumptions
- • All pods actively use their full allocated connection pool.
- • The database enforces a strict max_connections limit without a transactional proxy like PgBouncer buffering queues.
- • Scaling events are symmetric and apply uniform load across replicas.
Authoritative references
50-pod scaling event
Situation
A database accepts 500 connections. 20 are reserved for operations. The HPA scales out to 50 pods.
Result
Each pod must be strictly limited to a pool size of 9. Any value higher than 9 will cause connection errors at maximum scale.
Use the result with engineering judgement
- It assumes all pods are actively using their full pool.
- It does not account for PgBouncer transaction-level pooling dynamics, only hard connection counts.
Questions before you begin
Shouldn't I just use a proxy?
A proxy like PgBouncer helps, but you still need to limit the application pool so it doesn't exhaust the proxy's limit.
Why use floor instead of round?
Rounding up creates a scenario where scaling to max pods exceeds the absolute database connection limit, causing dropped transactions.
How do I handle multiple services using the same database?
You must allocate the database's max connections among the services first, then run this calculator individually for each service using its allotted fraction as the max connection limit.
Ready to run DB Pool Sizer?
Log in to open the full interactive workspace. Your completed result can be saved, revisited and exported as a private report.
Log in and start