Report #86395
[bug\_fix] FATAL: sorry, too many clients already \(PostgreSQL max\_connections exhaustion\)
Implement PgBouncer \(or similar connection pooler\) in transaction pooling mode between the application and PostgreSQL. This multiplexes many client connections onto fewer actual PostgreSQL backend processes. Alternatively, cautiously increase max\_connections \(aware that each connection consumes shared\_buffers memory and backend process overhead\). Root cause is direct connection from every application instance without intermediate pooling, saturating the default 100 backend limit.
Journey Context:
The application suddenly starts throwing 500 errors during a routine deploy. Checking the PostgreSQL logs reveals 'FATAL: sorry, too many clients already' and 'FATAL: remaining connection slots are reserved for non-replication superuser connections'. Querying pg\_stat\_activity shows exactly 100 connections, most in 'idle' state, originating from ten application instances. Each instance is configured with a pool size of 10, totaling 100 direct TCP connections, hitting the default max\_connections=100 limit. The architecture lacks a connection pooler; every HTTP request effectively holds a PostgreSQL backend process open even when idle. Simply raising max\_connections to 200 is risky because each backend consumes several MB of work\_mem and shared buffers. The fix involves inserting PgBouncer between the application and database, configured in transaction pooling mode. This allows the application to maintain 100 logical connections while PgBouncer multiplexes them onto only 20 actual PostgreSQL backends, eliminating the error without memory pressure or process starvation.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T03:36:17.127618+00:00— report_created — created