Pool sizing: the (cores × 2) + spindles formula and the two-layer stack

A team adds PgBouncer and sets pool_size = 200 — matching the application’s total client count. P99 rises instead of falling. Adding more backends to Postgres made things slower. The formula for sizing a pool is not “one connection per client”.

Why more Postgres backends does not mean more throughput

Each Postgres backend is an OS process. Past a small multiple of the CPU core count, additional active backends stop adding throughput and start costing it: more context switches, more contention on shared-memory structures (proc array during snapshot acquisition, lock table), more kernel scheduling overhead.

The HikariCP-popularised formula for the optimal active backend count on the Postgres side:

pool_size = (CPU cores × 2) + effective_spindle_count

• cores × 2 covers CPU-bound parallelism plus some hyper-threading benefit
• effective_spindle_count adds budget for I/O parallelism when storage can absorb multiple outstanding reads

On modern NVMe with a well-cached working set, spindle count is effectively 0 — the formula reduces to cores × 2. On a 16-core Postgres server with data in RAM: pool_size ≈ 32, not 200.

This is the PgBouncer pool_size (or default_pool_size), not the number of application workers.

Client-pool sizing per worker

The client-side pool (node-postgres, HikariCP, asyncpg) is sized differently — it is about in-worker concurrency, not Postgres core count:

worker_pool_size ≈ concurrent_requests × db_calls_per_request × avg_query_ms / request_budget_ms

Example: 100 concurrent requests per worker, 2 DB calls each at 5 ms, 50 ms total request budget:

= 100 × 2 × 5 / 50 = 20 connections

With 10 workers: 200 total client connections to PgBouncer — cheap (PgBouncer uses ~2 KB per client connection). PgBouncer multiplexes them onto the ~24-backend pool.

A concrete sizing worked example

Key PgBouncer knobs

pool_size (per-database backend pool target, default 20) — set this to (cores × 2) + spindles + ~50% headroom. This is the ceiling of real Postgres backends PgBouncer will maintain.

reserve_pool_size — extra backends PgBouncer can spin up under burst load (default 0; set ~25% of pool_size).

max_client_conn — total inbound client connections PgBouncer will accept (default 100; set to thousands — client connections are cheap).

server_reset_query = DISCARD ALL — SQL run against a backend before returning it to the pool; clears leaked session state.

query_wait_timeout — how long a client can wait for a backend before PgBouncer rejects it (default 120 s; production: 10–30 s for fast fail).