PostgreSQL Error 53300: Too Many Connections

PostgreSQL SQLSTATE 53300 is too_many_connections. It means the server has no connection slot available for the requested client. The PostgreSQL error-code appendix classifies it under insufficient resources.

If you cannot open another connection

Stop automatic retries first; repeated connection attempts will not free slots. On a managed database, use the provider’s query console or documented emergency-access procedure. On a self-managed Linux server, a local Unix-socket connection as the operating-system postgres user may still work if the server’s local authentication rules allow it:

sudo -u postgres psql -d postgres

PostgreSQL keeps superuser_reserved_connections slots for superusers after ordinary roles can no longer connect. On PostgreSQL 16 and later, reserved_connections slots are available to roles granted pg_use_reserved_connections; the defaults and thresholds are described in connection settings and predefined roles. These reserves can provide an administrative path while ordinary slots are exhausted, but they do not help once every slot is occupied. Managed providers may expose access through their own control plane instead of PostgreSQL superuser accounts.

If you regain access, inspect sessions before terminating anything. This query lists idle client sessions so you can identify their owner and application:

SELECT pid, usename, datname, application_name, state, state_change
FROM pg_stat_activity
WHERE backend_type = 'client backend'
  AND state = 'idle'
  AND pid <> pg_backend_pid()
ORDER BY state_change;

Only after confirming a session is safe to disconnect, terminate that specific PID:

SELECT pg_terminate_backend(12345);

Replace 12345 with the PID you inspected. Termination disconnects that session; it can roll back its active transaction and requires suitable privileges. Do not terminate sessions by age alone or run a bulk termination query. See PostgreSQL’s pg_terminate_backend documentation.

Count current client connections

Run this from an existing connection with permission to see the relevant sessions:

SELECT
  (SELECT setting::integer
   FROM pg_settings
   WHERE name = 'max_connections') AS max_connections,
  COUNT(*) AS client_connections,
  COUNT(*) FILTER (WHERE state = 'active') AS active,
  COUNT(*) FILTER (WHERE state = 'idle') AS idle,
  COUNT(*) FILTER (WHERE state = 'idle in transaction') AS idle_in_transaction
FROM pg_stat_activity
WHERE backend_type = 'client backend';

Then see which application or role owns the sessions:

SELECT
  usename,
  COALESCE(application_name, '(unset)') AS application_name,
  state,
  COUNT(*) AS connections
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY usename, application_name, state
ORDER BY connections DESC;

Ordinary roles may see limited information about other sessions; a superuser or a role with pg_read_all_stats can see all session details. If your count is incomplete, ask an administrator to run the checks. PostgreSQL documents pg_stat_activity in Monitoring Database Activity.

Check configured and reserved connection slots

Inspect the active connection settings from the same server:

SELECT name, setting, unit, source
FROM pg_settings
WHERE name IN (
  'max_connections',
  'reserved_connections',
  'superuser_reserved_connections'
)
ORDER BY name;

max_connections caps concurrent client connections and can only be changed at server start. PostgreSQL sizes some resources, including shared memory, based on this value, so increasing it blindly can raise resource use without fixing a connection leak or burst. See connection settings.

Since PostgreSQL 16, reserved_connections can reserve slots for roles granted pg_use_reserved_connections; superuser_reserved_connections keeps a final reserve for superusers. Preserve reserved slots for recovery and administration instead of treating them as routine application capacity. See the PostgreSQL 16 release notes and predefined roles.

Estimate an application connection budget

Use the values from pg_settings and the maximum connection limits configured for all other services. This calculator models a regular application role that cannot use reserved slots. It estimates configured pool capacity, not current usage, and does not connect to your server.

The estimate is a planning check, not a target to fill every slot. Leave headroom for administration and short-lived maintenance work. Roles granted pg_use_reserved_connections can use the reserved_connections slots; ordinary application roles should not rely on those reserves.

Reduce connection demand before raising the limit

Check the maximum pool size for every application process, worker, migration job, and service replica. The total possible connections across all of them must fit the server’s capacity and leave room for administrative access.

• Use a connection pool where appropriate and cap its total size across all application replicas, not just per process.
• Release connections promptly. Investigate idle in transaction sessions and clients that keep connections after requests finish.
• Avoid opening one database connection per web request or background task when a bounded pool can reuse sessions.
• If traffic arrives in bursts, queue work or apply backpressure rather than allowing an unbounded number of clients to connect.

Do not terminate sessions indiscriminately: an idle-looking connection may belong to a live transaction. Identify the application and owner first. If the server reports password authentication failure instead of exhausted slots, see PostgreSQL Error 28P01. Browse the PostgreSQL error troubleshooting index for other SQLSTATE guides.