too_many_connections Too Many Connections — SQLSTATE 53300

The server reached its connection limit and rejected the new connection.

• The error is written to the server log and returned to the client carrying SQLSTATE 53300.
• Any driver (libpq, JDBC, psycopg, npgsql, pgx) surfaces this code in its error object so you can branch on it programmatically.
• PL/pgSQL can trap it by name: EXCEPTION WHEN too_many_connections THEN.

Severity: ERROR  |  PostgreSQL versions: 12, 13, 14, 15, 16, 17

Most often seen under load or on under-provisioned servers; correlate it with system metrics (CPU, memory, disk, connection count) at the time of the error.

Active connections reached max_connections (minus reserved superuser slots).

Common causes:

• No connection pooling.
• Connection leaks in the application.
• Spikes in client instances.
• Long-lived idle connections.

Steps to resolve 53300:

1. Put a pooler in front (PgBouncer in transaction mode) — the standard fix.
2. Find leaks: SELECT count(*), state FROM pg_stat_activity GROUP BY state;.
3. Raise max_connections only with enough RAM — each backend costs memory.
4. Reap abandoned connections with idle_session_timeout.

Reference: PostgreSQL error codes — Class 53 (Insufficient Resources).