A million clients, four hundred connections

Reconstructs the two-line connection-rationing architecture that GitLab, Notion, Figma, OpenAI, Cloudflare and Supabase all converge on, with the measured cost of idle connections, the ceilings of a single-threaded pooler, and five published incidents. A reader leaves able to size each pool, choose a pooling mode with its semantic consequences in view, and capacity-plan the pooler tier as a first-class service.

What you get out of it

• Idle connections are not free: one active query slows more than 2x among 10,000 idle connections (Freund, 2020), and 1,000 idle connections cut read throughput 46% on a small RDS instance (AWS, 2020).
• Every published large deployment converges on two ration lines: a small in-process pool sized to the database host, and a transaction-mode pooler tier holding the idle clients.
• The pooler is itself a capacity-planned service: one core and roughly a thousand active clients per process; GitLab, ClickHouse and Crunchy all scale it as a per-core process fleet.
• Changing pool mode is an application-semantics migration: prepared statements and session SET maroon on server connections, a failure class that ran from 2017 driver issues until PgBouncer 1.21 in late 2023.
• Storms and recovery herds are open-loop failures; the bounded pool is the stability mechanism, and recovery needs a deliberate admission ramp (Honeycomb 2023, Quay.io 2020).

Scope

Why this, now. Figma's 2026 PGKeeper account and OpenAI's 2026 Postgres write-up both moved the frontier of this topic from connection reuse to pool-level admission control, which changes what teams should build at the pool.

What it does not cover. Read-replica routing policy, sharding, driver-internal retry semantics, and serverless engines that dissolve the connection limit inside the managed service.