PostgreSQL pooling with PgBouncer
PgBouncer can reduce backend connection pressure by pooling at the transaction or session level. With transaction pooling, per-pod pool sizes are typically smaller, but you still need to account for headroom and reserved operational access.
Example: usable connections of 600 across 20 pods gives 600 ÷ 20 = 30 connections per pod. With PgBouncer, you may keep pool sizes lower than in direct-to-Postgres setups.
FAQs
Does PgBouncer change max_connections? No. It changes how application connections map to backend connections, which can lower required pools.
Why reserve connections? Keep capacity for migrations, admin tooling, and emergency access.
Is memory still the driver? Yes. PostgreSQL defaults scale with DBInstanceClassMemory, even when pooling is used.
Open the preset
Start with a PgBouncer-friendly scenario and tune pool sizes as needed.
Open calculator with this preset