PostgreSQL 'FATAL: sorry, too many clients already' (or 'remaining connection slots are reserved for non-replication superuser connections'): how do I fix it with connection pooling instead of just raising max_connections?

Cause: The server has reached max_connections (default usually 100). Only the superuser_reserved_connections slots (default 3) remain, and they are kept for administrators, so ordinary roles are refused. Typical culprits are apps that open one connection per request or per worker without a pool, many app replicas each holding a large pool, serverless functions, and leaked connections that are never closed. Fix (best first): 1. See who holds the slots: SELECT usename, application_name, state, count(*) FROM pg_stat_activity GROUP BY 1,2,3 ORDER BY 4 DESC; Many 'idle' rows from one app means a leak or an oversized pool. 2. Fix the client side: use a bounded pool in the app (pool size times the number of processes and replicas must stay well below max_connections), always return connections in finally/context-manager blocks, and set idle timeouts. 3. Put a server-side pooler such as PgBouncer in front. In transaction pool mode a server connection is returned to the pool at the end of each transaction, so thousands of clients can share a few dozen server connections. Relevant PgBouncer settings: pool_mode, default_pool_size (default 20 per user/database pair) and max_client_conn (default 100; raising it may need a higher file descriptor limit). Caveat: in transaction mode do not rely on session state (SET, session-level prepared statements, advisory locks held across transactions); the PgBouncer docs list the limitations. 4. Only then consider raising max_connections in postgresql.conf. It needs a restart, and PostgreSQL allocates shared memory based on it, so a very high value costs memory and does not fix leaks. 5. Do not give application roles superuser just to get past the limit. Verify: SELECT count(*) FROM pg_stat_activity; stays comfortably below SHOW max_connections; during load the app no longer logs the error, and PgBouncer's SHOW POOLS shows clients waiting rarely. Sources: https://www.postgresql.org/docs/current/runtime-config-connection.html https://www.pgbouncer.org/config.html