More PostgreSQL connections are rarely the fix

When an application starts failing with "too many clients", the reflex is to raise max_connections. Every connection is a separate server process with its own memory, so a larger limit mostly moves the problem to RAM and context switching.

First look at what the connections are doing:

SELECT state, count(*) FROM pg_stat_activity GROUP BY state ORDER BY 2 DESC;

A large number of idle connections means the application opens more than it uses. Often the real cause is a pool in each of many worker processes, each sized for the whole load.

The usual answer is a pooler such as PgBouncer in front of the database, with a modest pool size on the server side. Transaction pooling gives the best reuse, but session state does not survive between transactions, so check whether the application relies on SET commands, advisory locks or temporary tables before switching.