Example 1
- 8 cores
- 3 instances
- cap 100
51
What pool at 8 cores and 3 instances? 51. A heuristic, not a live DB.
Database Connections Calculator
Type cores, instances, and an optional cap. 8 and 3 give 51. 4 and 2 give 18. 16 and 4 give 132. (cores×2+1)×instances, not a PostgreSQL probe.
This is the PostgreSQL cores×2+1 heuristic per instance, not a max_connections read. Request windows sit on API rate limit.
Results
Enter data and click Calculate.
How it works
Database Connections Calculator in this calculator multiplies a heuristic by instances. 8 cores and 3 instances give 51. 4 and 2 give 18. 16 and 4 give 132. The formula is (cores × 2 + 1) × instances. The calculator does not read max_connections from a server.
Field db-cores is cores. Field db-inst is application instances. Field db-max-conn is an optional cap. 8 × 2 + 1 = 17, times 3 is 51. 4 × 2 + 1 = 9, times 2 is 18. 16 × 2 + 1 = 33, times 4 is 132.
51 does not come from pg_settings. 18 is not PgBouncer. 132 at cap 100 only shows the sketch is over the typed ceiling. The calculator does not log into a database.
Cache hit ratio next door counts requests. API rate limit times a window. Here 8 and 3 stay 51, the pool from the formula alone.
Type 8, 3, and 100, then Calculate. The result is 51. A comma is not needed; the fields are integers. Zero cores give no pool.
8 and 3 give 51. 4 and 2 give 18. 16 and 4 give 132. Another instance count at 8 changes 51.
Formula
pool = (cores × 2 + 1) × instances. db-max-conn is a typed ceiling, not a probe.
How to use
- Type 8 cores, 3 instances, and cap 100.
- Click Calculate. The result is 51.
- 4 and 2 give 18. 16 and 4 give 132.
- A heuristic, not live max_connections.
- The next card times an API window, not a pool.
8 and 3 give 51
Pool = (cores × 2 + 1) × instances. 8 and 3 give 51. Not a live DB.
- Database
- Your numbers, not a probe. 16 and 4 give 132. Not max_connections.
- Connections
- A sketch from the formula. 4 and 2 give 18. Not pg_settings.
- Calculator
- The calculator result. 8 cores and 3 instances leave 51.
Examples
Example 2
- 4 cores
- 2 instances
- cap 200
18
What pool at 4 and 2? 18.
Example 3
- 16 cores
- 4 instances
- cap 100
132
What pool at 16 and 4? 132. A sketch, not a max_connections probe.
Related calculators
Common questions
What pool at 8 cores and 3 instances?
51. (8 × 2 + 1) × 3. A heuristic, not a live DB.
What about 4 and 2?
18. (4 × 2 + 1) × 2.
What about 16 and 4?
132. (16 × 2 + 1) × 4.
Is this PostgreSQL max_connections?
No. The calculator does not connect. You type the cap.
Why the cap field of 100?
A typed ceiling. 51 fits in 100. 132 at 100 only compares the sketch.
Is 51 PgBouncer?
No. Only cores×2+1 times instances.
Does zero cores count?
No. Cores and instances must be positive.
How is this different from API rate limit?
That card turns 60 and 15 min into 900. Here 8 and 3 give 51.
Does a comma in 8,5 work?
The field is an integer. The examples keep 8, 4, and 16.
Knowledge sources
The calculator counts bits, bytes or throughput from your numbers. Below are SI and bit definitions (NIST).
Page updated in 2026.
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.