Why do I get "sorry, too many clients already"?

Every connection slot the server was configured with is occupied, so it refuses the next login with that fatal error rather than accepting a session it cannot serve. The limit is max_connections, minus the slots held back for superusers, and it is a hard ceiling fixed when the server started. The message names the symptom; it never names which sessions took the slots.

The distinction that decides what you do next

Slots are consumed by sessions, not by work. So the first question is whether the sessions occupying them are doing anything, and the answer is usually no.

If most are idle, the application is holding connections it is not using, and the ceiling is irrelevant. If most are idle inside a transaction, you have a correctness problem that is presenting as a capacity problem, and it is holding locks as well as slots. If most are genuinely running queries, you have found the real thing, and raising the limit will convert refused logins into a slower database for everyone, which is the worse of the two failures.

There is a second trap in the wording. The same error text is produced by a pooler in front of the database when its own limit is reached, and that limit has nothing to do with max_connections. Reading the message and immediately editing the server configuration is how an afternoon disappears.

Getting back in, and then keeping the slot

A handful of slots are reserved so that an administrator can still connect when everything else is refused, which is what superuser_reserved_connections is for. Connecting as an ordinary monitoring role does not get you one of them, and that is worth discovering before an incident rather than during it. From PostgreSQL 16 there is a second reserve, reserved_connections, which can be granted to a non-superuser role through a predefined role, so an operator account can be given a way in without being given the world.

Once you are in, the counters in pg_stat_database separate sessions that ended normally from sessions the server had to abandon, which is how you tell an application that is churning connections from one that is simply holding them. Those columns arrived in PostgreSQL 14.

The durable answer is that the number of server connections should stop tracking the number of application threads at all, which is what connection pooling and PgBouncer is about. If the count climbed in a burst rather than drifting up over weeks, the pattern to recognise is a connection storm.