Database Connections Calculator
Set a database connection pool too small and requests queue; set it too large and the database risks running out of memory or hitting its own connection ceiling. This calculator applies the common cores×2+1 sizing rule per instance and, if you provide your database’s max_connections, tells you whether your planned pool fits.
Results
Enter data and click Calculate.
What a connection pool is
A pool is a set of pre-opened DB connections that the app borrows and returns instead of opening TCP + auth on every query. This calculator uses the cores × 2 + 1 rule per instance and — if you enter max_connections — checks whether the total pool blows past the database limit.
Pool too small: queues and timeouts
When concurrent requests needing DB outnumber free connections, threads wait in the pool queue. Symptoms: rising p95/p99 latency, “connection acquisition” timeouts, lower RPS while app CPU looks idle.
Example: 80 concurrent requests needing DB, pool=20 → most wait. Raising the pool (within the DB limit) often clears timeouts — if the database has IOPS/CPU to handle more concurrency.
Pool too large: contention and max_connections
- Each connection uses memory on the database.
- Too many concurrent queries increase locks and context switches — throughput can fall.
- Exceeding
max_connectionsmeans “too many connections” errors for new clients.
Patterns: web, API, microservices
- Monolith / few instances — per-instance heuristic × N often works; leave headroom for admin/monitoring.
- High-RPS API — pair with rate limits; more traffic does not automatically mean a bigger pool if queries are short and well indexed.
- Microservices / autoscaling — N pods × pool easily exceeds the DB limit → PgBouncer / ProxySQL or a shared proxy-side pool.
Examples
- 8 cores × 3 instances → 17 per instance, total pool 51.
- Pool 20, 80 concurrent DB calls → typical queues/timeouts; raising toward ~40 (if max_connections allows) usually cuts wait errors.
- 16 cores × 5 instances, max_connections=100 → recommended 165 → over sized; cut pool, fewer replicas, or add proxy pooling.
FAQ — database connections
- What happens when the pool is too small?
- Requests wait for a free connection: latency rises, acquisition timeouts appear, RPS drops even if app CPU looks idle.
- What happens when the pool is too big?
- The DB uses more RAM, query contention grows, and you risk “too many connections” without real throughput gains.
- How do I relate pool size to traffic and rate limits?
- Peak concurrent DB callers ≈ traffic × connection hold time. Rate limits cap inflow; the pool must cover peak concurrency, not average RPS alone.
- Can I simply set max connections very high?
- Technically yes, but each connection costs memory and raises overload risk. Prefer a sane limit + proxy pooling over an “infinite” ceiling.
- Is cores×2+1 a hard rule?
- It is a starting heuristic (PostgreSQL/HikariCP), not a law of physics — tune with query mix and measurements.
- When do I need PgBouncer?
- When many instances/pods multiply connections past the DB limit, or you want a large logical app pool on a small real DB pool.
- Should I leave headroom in max_connections?
- Yes — room for admin, migrations, monitoring, and other services sharing the database.
- Do read replicas change sizing?
- Yes — size pools separately for primary (writes) and replicas (reads) instead of one blunt total.