In PostgreSQL every client connection is served by its own server process. max_connections caps how many exist at once, and a few slots (superuser_reserved_connections) are kept so an administrator can always get in. That cap is about memory: each backend reserves working memory, so a small server with a large limit can swap itself to death under load.
The common way to hit the limit is not real traffic but a leak. A client opens a session, starts a transaction, and never commits or disconnects. In pg_stat_activity such sessions show the state idle in transaction. They hold a slot, and often locks too, while doing nothing. A busy server looks idle, and new clients get "too many clients already" or "remaining connection slots are reserved".
Look before you act. As a superuser, group pg_stat_activity by user, application, and state, and check how old each transaction is (xact_start). Ending sessions with pg_terminate_backend frees slots immediately but treats the symptom. Contain the client instead: ALTER ROLE ... CONNECTION LIMIT n caps one role's share, and idle_in_transaction_session_timeout makes the server end sessions that sit in an open transaction. In front of many application servers, a connection pooler such as PgBouncer keeps the number of real backends small. Raising max_connections is the last resort, not the first: it needs a restart, costs memory, and a leak will fill any number you choose.