Report #7621
[bug\_fix] PgBouncer no more connections allowed \(max\_client\_conn\) or pool exhaustion
Increase \`max\_client\_conn\` to a very high value \(e.g., 10000\) to handle all application instances, and strictly control Postgres connection usage via \`default\_pool\_size\`, \`reserve\_pool\_size\`, and \`max\_user\_connections\`. Root cause is confusion between max\_client\_conn \(limit of clients allowed to connect to PgBouncer itself\) and default\_pool\_size \(limit of actual Postgres connections per user/database pool\); when many application instances connect to PgBouncer, they exhaust max\_client\_conn even if they are idle, preventing new connections despite Postgres having capacity.
Journey Context:
A DevOps engineer deployed PgBouncer 1.20 in front of an AWS RDS Postgres instance to handle 100 microservice pods. They configured \`max\_client\_conn = 100\` thinking this matched RDS max\_connections, and \`default\_pool\_size = 20\`. During deployment, the first 10 pods started fine, but pods 11-100 failed to start with 'no more connections allowed \(max\_client\_conn\)'. The engineer checked RDS and saw only 8 active connections, confirming Postgres wasn't the bottleneck. They increased default\_pool\_size to 50, but the error persisted. After reading the PgBouncer documentation carefully, they realized max\_client\_conn counts connections \*to PgBouncer\*, not to Postgres. With 100 pods trying to connect, they hit the 100 limit immediately. The fix was setting max\_client\_conn to 10000 \(allowing all pods to connect to PgBouncer\) while keeping default\_pool\_size at 20 to actually limit Postgres connections. The pods then started successfully, and PgBouncer properly multiplexed the 100 client connections onto 20 Postgres connections.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T03:16:53.831304+00:00— report_created — created