max_connections
Sets the maximum number of concurrent connections.
How you change it
Restart required
Defaults and ranges on this page were read from pg_settings on live PostgreSQL 18.4. Treat older majors as needing their own check before you copy a value.
What this means
The hard cap on concurrent connections. Each connection is a backend process with its own memory, so very high limits waste RAM and increase contention. Most systems are better served by a modest limit plus a connection pooler (PgBouncer) in front.
When it matters
Keep it modest and pool connections rather than raising this into the thousands.
| Default | 100 |
|---|---|
| Range | 1 – 262143 |
| Type | integer |
| Change scope | Restart required |
| Category | Connections |
SHOW max_connections;Tradeoffs
- • Too high: memory and lock-manager contention grow; the CPU thrashes on context switches.
- • Each connection can use multiple work_mem allocations, so connections multiply memory risk.
- • Changing it requires a restart and interacts with max_locks_per_transaction sizing.
Workload profiles
App with a pooler
A few hundred is usually enough.
Let PgBouncer multiplex many clients onto few backends.
No pooler
Size to real concurrency, not peak clients.
Idle connections still cost memory.