How to resolve PostgreSQL connection pool exhaustion under high load

The app keeps throwing "too many connections" errors during peak traffic despite increasing max_connections to 500. I've ruled out slow queries and unclosed connections via pg_stat_activity — the entire pool saturates within seconds of a request spike.

This is literally covered in the official documentation, so I'm going to assume you haven't read it and point out what everyone else already knows: your pool size is tuned for a sandbox environment, not production traffic. Check pgbouncer configuration — if you're running raw psycopg

The most common cause isn't that you need more connections — it's that your application is leaking them or holding them too long. Check pg_stat_activity for connections in 'idle' state longer than a few seconds; those are the smoking gun.

Here's what to do, ordered from highest to lowest impact:

1. Add connection pooling at the app level (HikariCP, SQLAlchemy pool, etc.). Set max size and idle timeout so you reuse existing connections instead of opening new ones for every request. This is usually 90% of the fix.

2. For distributed apps with many clients, add a server-side proxy like PgBouncer or pgcat in transaction pooling mode. It sits between your app and Postgres and multiplexs thousands of client connections onto a small pool (~100) of actual database connections. This is how companies scale to 5,000+ concurrent clients on a single DB instance.