Postline

The workbench · Free tool

Count the connections.
Include the rollout.

A planning worksheet for the database change review. Adjust the example, see what multiplies, and take the result back to your team.

The example is editable. Your numbers stay in this browser tab.

Using PgBouncer? Try a database-side example.

Two user/database pairs target the same PostgreSQL server through two PgBouncer instances, plus one extra instance during rollout. Each pair allows 10 server connections plus 5 reserve connections: 3 × 2 × 15 = 90. Add 5 direct operational connections for a total bound of 95, against a planning budget of 70.

Each row represents one pair across the pooler instances. This example assumes the reserve pools can activate and no lower per-user or per-database caps apply. Check overrides and caps in your configuration. Client connections are a separate budget. These are illustrative values, not recommended settings. See the PgBouncer pool settings.

Loading this example replaces the values below.

1. Set your planning budget
2. Count every database-side consumer

Count independently created pools. Extra rollout instances are added to the steady-state count.

Upper bound48
Upper bound12
Upper bound5

3. Review the arithmetic

5 slots left in your planning budget.

65 potential connections / 70 planned slots

This fits the budget you entered. It does not prove the database can run that workload: check latency, queueing and resource use in a representative rehearsal.

Download your worksheet ↓

What would make your next change easier to review? Suggest a task for a review pack ↗. You can share feedback without requesting emails.

What this calculates

For each consumer: (instances + extra rollout instances) × connections each. The sum is compared with maximum connections minus unavailable slots and chosen headroom. These are configuration bounds, not a measurement of active queries or performance.

The starting example uses direct application connections. Open the PgBouncer example above to load server-pool rows with rollout overlap and reserve capacity. Count database-side server pools instead: include each pooler instance, user/database pair and applicable reserve-pool capacity. Overrides and per-user/database caps can lower the effective bound. Keep client concurrency in its own worksheet; do not count both sides of the same pool.

Check the actual role and provider limits. PostgreSQL’s reserved and superuser-reserved slots have different access rules. Any headroom is your planning choice, not a universal recommendation.

Sources checked 8 October 2026: PostgreSQL 18 connection settings and PgBouncer configuration. Read issue 002 for the operational rehearsal.

Review what the connection must remember

A pool that fits the budget can still break session-dependent application behavior. Before changing pooling modes, map each consumer’s endpoint, versions and dependencies, then record what your rehearsal actually showed.

Download the free pooling review worksheet ↓ An editable Markdown file with source links and blank evidence fields. No email or account required.

Put the next decision on the desk.

Request future briefs, and tell us which database task needs a clearer checklist. The proposed $49 one-time change-review packs would provide a focused rehearsal and editable review documents for a specific change.