sorry, too many clients already

What it means

Each connection to PostgreSQL takes one of a fixed number of slots, set by max_connections (100 by default). When they’re all taken, the server refuses new connections with SQLSTATE 53300 (too_many_connections). Your query isn’t the problem; the server has no room for another session.

A few slots are held back, so you see different messages as the server fills up:

All of them have SQLSTATE 53300.

Common causes

1. Pools that add up to more than the server allows. Each app process or container keeps its own pool. Ten instances with a pool of 20 want 200 connections from a server that allows 100.
2. Idle sessions that never close: desktop clients, notebooks, crashed workers, and sessions left idle in transaction.
3. Short-lived clients that each open a connection, such as serverless functions, without a pooler in front.
4. A small max_connections for the number of clients you run.
5. A per-role or per-database limit (CONNECTION LIMIT) that’s lower than the app needs.

How to fix it

See who holds the slots

The superuser slots exist for this moment: connect as a superuser and run:

SHOW max_connections;

SELECT usename, application_name, client_addr, state, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY 1, 2, 3, 4
ORDER BY 5 DESC;

Look for one application or address with far more connections than it needs, and for many rows in state idle or idle in transaction.

Close idle sessions

SELECT pid, usename, application_name, pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
  AND state = 'idle'
  AND state_change < now() - interval '30 minutes'
  AND usename = '<user>';

pg_terminate_backend ends the session; its client gets FATAL: terminating connection due to administrator command the next time it uses it. You need to be a superuser, the same role, or a member of pg_signal_backend (only a superuser can end a superuser’s session).

To stop them piling up again, let the server close them (idle_session_timeout needs PostgreSQL 14 or later):

ALTER ROLE <user> SET idle_session_timeout = '30min';
ALTER ROLE <user> SET idle_in_transaction_session_timeout = '5min';

These apply to new sessions of that role.

Make the pools fit

Add up the maximum pool size of every process that connects, and keep it below max_connections minus the reserved slots. For many short-lived or bursty clients, put a pooler such as PgBouncer (or your provider’s pooled connection string) in front, so many clients share a few server connections.

Raise max_connections, carefully

ALTER SYSTEM SET max_connections = 200;

This takes effect only after a restart, not a reload. Each connection is a separate server process with its own memory, so more connections cost RAM; a pooler is usually the better fix. On hosted databases, change it in the provider’s parameter settings.

Check role and database limits

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

ALTER ROLE <user> CONNECTION LIMIT 50;      -- or -1 for no limit
ALTER DATABASE <database> CONNECTION LIMIT -1;

Keep a slot for monitoring (PostgreSQL 16 and later)

Set reserved_connections (server start only) and grant pg_use_reserved_connections to the role your monitoring or admin tools use, so they can still get in when the app has used everything else.

Reproduce it

A temporary PostgreSQL 18.6 server with max_connections=6, superuser_reserved_connections=1 and reserved_connections=1, filled by sessions running select pg_sleep(25). After four sessions from an ordinary role, the fifth gets:

psql: error: connection to server at "localhost" (::1), port 55414 failed: FATAL:  remaining connection slots are reserved for roles with privileges of the "pg_use_reserved_connections" role

A role granted pg_use_reserved_connections takes the next slot. After that, ordinary roles and that role both get:

psql: error: connection to server at "localhost" (::1), port 55414 failed: FATAL:  remaining connection slots are reserved for roles with the SUPERUSER attribute

A superuser takes the last slot, and then everyone, superusers included, gets:

psql: error: connection to server at "localhost" (::1), port 55414 failed: FATAL:  sorry, too many clients already

The server log shows 53300 for each:

2026-10-09 10:09:25.568 UTC [96] 53300 FATAL:  sorry, too many clients already

PostgreSQL 15.19 words the superuser case differently:

psql: error: connection to server at "localhost" (::1), port 55411 failed: FATAL:  remaining connection slots are reserved for non-replication superuser connections

Per-role and per-database limits, after CREATE ROLE seo_lim LOGIN CONNECTION LIMIT 1 and CREATE DATABASE seo_pgconn CONNECTION LIMIT 1, each with one session already open:

psql: error: connection to server at "localhost" (::1), port 55414 failed: FATAL:  too many connections for role "seo_lim"
psql: error: connection to server at "localhost" (::1), port 55414 failed: FATAL:  too many connections for database "seo_pgconn"

A superuser could still connect to the full seo_pgconn database.

In Inlet

Inlet’s Activity monitor lists the server’s sessions, so you can see which application or user holds the connections, and cancel or terminate the ones you don’t need.