too_many_connections sorry, too many clients already — 53300

Symptoms

The server has reached max_connections and cannot open another backend. Every connection slot (minus those reserved for superusers) is in use, so new connection attempts are refused.

• New connections fail with a FATAL and SQLSTATE 53300.
• Existing sessions keep working; only new logins are rejected.
• Almost always a sign of connection leakage or missing pooling.

What the server log shows

FATAL:  sorry, too many clients already

Why PostgreSQL raises this — what the manual says

Section 19.3.1 Connection Settings (max_connections):

“At most max_connections connections can ever be active simultaneously.”

Each connection consumes a backend process and memory. When active connections reach max_connections, the postmaster rejects further clients with this FATAL. It is almost always a sign of connection leakage or missing pooling, not a need to simply raise the limit.

Common causes

• An application opening connections without closing them (leak).
• No connection pooler in front of a high-concurrency app.
• A pool sized larger than max_connections.
• Many idle sessions holding slots.

Relevant GUC parameters

How to fix it

1. Put a pooler in front (PgBouncer in transaction mode) and size it sanely.
2. Find and fix leaks; ensure connections are returned/closed.
3. Identify idle hogs: SELECT state, count(*) FROM pg_stat_activity GROUP BY state;.
4. Raise max_connections only after pooling — it costs memory and a restart.

Diagnostic query

-- Connections by state and application
SELECT application_name, state, count(*)
FROM pg_stat_activity
GROUP BY application_name, state
ORDER BY count(*) DESC;

Lots of idle rows from one app points at a leak or oversized pool.

Related & next steps

• SQLSTATE 53300 — Too Many Connections (full reference)
• Message: remaining connection slots are reserved
• Message: too many connections for role

Reference: PostgreSQL 18 Section 19.3 “Connections and Authentication”.