PostgreSQL rejected a new session because available connection slots were exhausted. The relevant server value is Configured per server; typically 100 by default, and reserved slots mean ordinary users can be rejected before the raw setting is reached.
Why does this error happen?
- Application pools multiply across processes or deployments.
- Idle or leaked sessions hold slots.
- A managed-provider cap or reserved connections reduce ordinary-user capacity.
How do you diagnose it?
- Run SHOW max_connections on the affected server.
- Group pg_stat_activity by application_name, usename, state, and client address.
- Compare every pool's maximum multiplied by its live instance count.
SHOW max_connections;
SELECT application_name, usename, state, count(*)
FROM pg_stat_activity
GROUP BY 1, 2, 3
ORDER BY 4 DESC;How do you fix it?
- Close leaked sessions and right-size client pools.
- Use a transaction pooler for bursty serverless workloads where compatible.
- Raise max_connections only after memory and provider constraints are understood.
How do you prevent it from recurring?
Turn the confirmed cause of SQLSTATE 53300 — too_many_connections into an observable boundary for PostgreSQL. Track the relevant request count, token volume, payload size, execution time, connection pressure, billing state, or upstream health before it reaches the documented failure condition. Preserve the platform request ID and timestamp so future incidents can be correlated without logging sensitive payloads.
Test the fix under representative concurrency and failure injection, not only with one successful request. Alert on remaining headroom and repeated retries, and keep the linked limit page and official error source with the runbook so responders can distinguish a configuration problem from temporary service pressure or account state.