Connection Limit Sizing Calculator

Work out connection limit sizing instantly with clear inputs, formula shown and shareable results.

About Connection Limit Sizing Calculator

Total connection demand is instances multiplied by pool size, and it must stay below the server limit with headroom for administrative sessions, replication slots and monitoring. Each PostgreSQL connection is a backend process costing several megabytes, so raising max_connections trades memory that the buffer pool would use better — which is the argument for an external pooler such as PgBouncer.

Formula

Connection demand

requested = instances x pool size; server memory = requested x per-connection memory; utilisation = requested / max_connections

Worked example

With the default values below, Connection Limit Sizing Calculator returns Connections the fleet can open of 240. Change any input above and every figure here is recalculated in your browser.

Inputs used

Application instancesminimum 1: 24
Pool size per instanceminimum 1: 10
Memory per connectionminimum 0.1 MB: 9 MB
Configured max connectionsminimum 1: 300

Results

Connections the fleet can open: 240
Server memory consumed by connections: 2.11 GiB
Share of max_connections used: 80.0%
Assessment: Within a safe margin

Step by step

1Values used
2Connection demand
3Connections the fleet can open= 240
4Server memory consumed by connections= 2,264,924,160
5Share of max_connections used= 80.0
6Assessment= Within a safe margin

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why not just raise max_connections?

Each connection costs memory and adds scheduling overhead. Beyond a few hundred, throughput falls because the database spends more time context switching than executing queries.

What breaks during a rolling restart?

Old and new instances briefly coexist, so peak connection demand can be double the steady state. Size the limit for that overlap, not the average.