PostgreSQL Error 53300

SQLSTATE

53300

Condition name

too_many_connections

Product

PostgreSQL

Versions

PostgreSQL 13 to 18 (reserved-slot wording changed in PostgreSQL 16)

Category

Connections, Authentication & Privileges

Last reviewed

24 October 2026

What it means

SQLSTATE 53300 means the server refused a new connection because a connection limit was reached: max_connections for the whole server, the reserved slots, or a CONNECTION LIMIT on the role or database.

max_connections sets the maximum number of concurrent connections to the server (typically 100). When every slot is in use, a new connection fails at once with sorry, too many clients already and SQLSTATE 53300 (too_many_connections). The last few slots are held back: superuser_reserved_connections (default 3) for superusers and, from PostgreSQL 16, reserved_connections (default 0) for roles with privileges of pg_use_reserved_connections. When only reserved slots remain, other roles get one of the "remaining connection slots are reserved" messages instead. Separately, CONNECTION LIMIT on a role or a database caps that role or database, and exceeding it gives "too many connections for role" or "for database"; superusers are not subject to these two limits.

Each PostgreSQL connection is a separate server process with its own memory, and the documentation notes that the server sizes some shared memory directly from max_connections. So the usual cure is not a much higher limit but fewer connections: a connection pool in the application or a pooler such as PgBouncer in front of the server, and closing sessions that sit idle, especially "idle in transaction" ones that also hold locks.

Common causes

• Many application instances (web workers, containers, serverless functions) each open their own connections or their own pool, and together they exceed max_connections.
• Connections are leaked: the application opens them and does not close or return them to the pool, so idle sessions accumulate.
• Sessions left "idle in transaction" by code that started a transaction and never committed, which keep their slots and their locks.
• A traffic spike or slow queries: each request holds its connection longer, so more are open at once.
• A CONNECTION LIMIT set on the role or database (ALTER ROLE / ALTER DATABASE ... CONNECTION LIMIT) that is lower than the application's pool size.
• A managed service plan whose max_connections is small for the instance size.

Diagnose it

Read-only These queries only read the system catalogs (pg_catalog, information_schema) and statistics views such as pg_stat_activity and pg_locks. They do not change data, roles or settings, so they are safe to run first.

SELECT current_setting('max_connections')::int AS max_connections,
       current_setting('superuser_reserved_connections')::int AS superuser_reserved,
       current_setting('reserved_connections')::int AS reserved;

SELECT state, count(*) AS connections
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state
ORDER BY connections DESC;

SELECT usename, datname, application_name, client_addr,
       count(*) AS connections
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY usename, datname, application_name, client_addr
ORDER BY connections DESC;

SELECT pid, usename, application_name, client_addr, state,
       now() - state_change AS in_state_for
FROM pg_stat_activity
WHERE state IN ('idle', 'idle in transaction')
ORDER BY in_state_for DESC;

SELECT rolname, rolconnlimit
FROM pg_roles
WHERE rolconnlimit <> -1;

SELECT datname, datconnlimit
FROM pg_database
WHERE datconnlimit <> -1;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

ALTER ROLE app_user SET idle_in_transaction_session_timeout = '5min';

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND now() - state_change > interval '30 minutes'
  AND usename = 'app_user';

ALTER ROLE app_user CONNECTION LIMIT 40;

ALTER SYSTEM SET max_connections = 200;
-- then restart the server

Examples

Every connection slot is in use

With superuser_reserved_connections at its default of 3, ordinary roles see this message once only the reserved slots are free; "sorry, too many clients already" appears when every slot, including the reserved ones, is taken. The documentation describes the reserved slots (Connections and Authentication settings) but does not print the messages, so the text is quoted from the PostgreSQL 18.6 source code. This example needs a running PostgreSQL server (enough concurrent connections to fill max_connections), which PGlite does not provide, so it was not reproduced here.

-- max_connections = 100, superuser_reserved_connections = 3
-- 97 application sessions are already connected; a 98th tries:
-- psql "host=db.example.com dbname=shop user=app_user"

FATAL:  remaining connection slots are reserved for roles with the SUPERUSER attribute

A role with a CONNECTION LIMIT

The documentation describes CONNECTION LIMIT (CREATE ROLE) but does not print this message, so the text is quoted from the PostgreSQL 18.6 source code. This example needs a running PostgreSQL server (several concurrent logins as one role), which PGlite does not provide, so it was not reproduced here.

ALTER ROLE app_user CONNECTION LIMIT 2;

-- app_user already has 2 sessions; a third login:
-- psql "host=db.example.com dbname=shop user=app_user"

FATAL:  too many connections for role "app_user"

All slots taken, superuser slots included

The message text is quoted from the PostgreSQL 18.6 source code; the documentation describes max_connections but does not print it. This example needs a running PostgreSQL server (every connection slot in use), which PGlite does not provide, so it was not reproduced here.

-- Every one of the max_connections slots is in use and another client connects:
-- psql "host=db.example.com dbname=shop user=postgres"

FATAL:  sorry, too many clients already

How to prevent it

Budget connections: list every application, job and tool that connects, give each a pool size, and keep the total below max_connections minus the reserved slots, with headroom for deployments (old and new instances overlap). Use a pooler for many small clients and serverless functions.

Set idle_in_transaction_session_timeout for application roles, alert when connections pass about 80 percent of the limit, and keep superuser_reserved_connections so an administrator can always get in to investigate.

Common questions

Learn more on CodeWithSQL

• AWS RDS Proxy
• Best PostgreSQL monitoring tools

Official documentation

• Connections and authentication settings (max_connections, reserved slots)
• CREATE ROLE (CONNECTION LIMIT)
• The cumulative statistics system (pg_stat_activity)
• Server signaling functions (pg_terminate_backend)

Last technically reviewed 24 October 2026; examples and diagnostics run on PostgreSQL 18.6 documentation; SQL-level parts in PGlite 0.5.11. SQL-level examples were run in PGlite (PostgreSQL compiled to WebAssembly); examples that need a running server are shown as documented in the PostgreSQL documentation.