Connection limit

`max_connections` sets the number of client connections PostgreSQL will accept concurrently. A large value is not automatically better: it permits more simultaneous work, but can push a modest server into overload. Changing it requires a PostgreSQL restart. section 6.3

The tempting mistake is to raise the limit for every expected client. With `max_connections = 2000`, a pgbench run at 2,000 clients reached only 352 TPS while average latency rose to 5,535 ms. Throughput stayed broadly flat across much lower client counts, but latency did not recover until 32 clients or fewer. section 6.3

Compare throughput with latency rather than treating a TPS plateau as proof that the server is healthy. The high-client runs trade response time for concurrency. section 6.3

Connection limits also interact with memory settings. `work_mem` can be allocated per execution-plan node for each running query, so allowing many sessions while using an oversized `work_mem` can create memory demand far beyond available RAM. In a stress test with 1,000 clients, `shared_buffers = 12GB` and `work_mem = 2GB`, the workload stalled and Linux's OOM killer terminated a PostgreSQL process. section 6.2

Treat a connection limit as a capacity decision:

• Test realistic client counts with pgbench, recording both TPS and average latency. section 6.3
• Size `max_connections` alongside `work_mem`, query complexity, and available RAM rather than independently. section 6.2
• Investigate severe memory pressure in system logs; the Linux OOM killer may terminate PostgreSQL or another necessary process. section 6.2