pgbouncer limits × rotating creds
learned something today about pgbouncer in a multi-client setup.
we run 3 postgres instances — a primary and 2 replicas. pgbouncer sits in front with just 2 pool definitions: mobula and mobula ro (read only). the ro pool load-balances across both replicas, but from pgbouncer's perspective it's still just 2 pools.
we had configured min 50 connections per pool. fine on paper. but each additional user spins up its own pool instance, and the floor stacks up fast.
the hidden ceiling: max_client_conn was set to 150 total. we tried to scale to 200 and pgbouncer silently capped us, killing everything above.
this is what caused the latency we spent today debugging. yesterday our infra lead shipped a rotating credentials mechanism — fresh creds spin up fresh pool instances, and under load that pushed us past the 150 cap. half the connections were getting dropped mid-query.
fix was either raising max_client_conn, or dropping the per-pool minimums so rotations don't burn through the budget.
lesson: any time you add something that opens new pools (rotating creds, multi-tenant, replicas), revisit every min-connection setting. the math compounds fast.