All Your GUCs in a Row: max_connections
max_connections is described as a memory budget and circuit breaker rather than a true capacity dial, since actual query throughput is bounded by CPU cores and storage, not connection slots. The setting requires a postmaster restart to change, defaults to 100, and drives shared memory allocation (lock manager hash tables, PGPROC entries, predicate locks) whether or not connections are used. PostgreSQL 14's snapshot scalability fix made idle connections cheap, but active connections beyond core count still degrade throughput sharply. Cloud providers like AWS RDS and Azure raised default max_connections dramatically (formulas yielding up to 5,000 based purely on RAM), which removes the early, cheap 'too many clients' error that used to force teams to adopt connection poolers, instead deferring failure to catastrophic server-side outages during traffic spikes. The recommendation is to use a pooler like PgBouncer in transaction mode, keep max_connections in the 100-300 range, cap per-role connections, and use idle_in_transaction_session_timeout to reclaim leaked slots.