A PostgreSQL backend process handles a client connection and executes its database work. PostgreSQL uses a client-server, multiprocess design: each client connects to a backend process, while other internal processes support the server. section 1.5.1
Figure 1.1 How the PostgreSQL client-server architecture works
Use the architecture diagram to trace the client connection to its PostgreSQL backend process and distinguish it from internal server processes. section 1.5.1
The tempting mistake is to equate more client connections with more useful parallelism. Because PostgreSQL follows a process-per-user model, every connection adds operating-system scheduling, process-accounting, inter-process communication, and memory overhead. section 6.3
Excessive backend processes can produce several operational symptoms:
- CPU context switching can consume more time than query execution, causing process thrashing. section 6.3
- Excessive memory use can push data in and out of swap, slowing execution because disk access is slower than RAM. section 6.3
- Idle connections still require backend processes and make connection management costly, even after PostgreSQL 14 reduced snapshot-acquisition bottlenecks. section 6.4.2
Diagnosing connection overload
Inspect pg_stat_activity to compare requested connections with genuinely active database work. A workload with 5,000 connections may run only 15–30 active tasks concurrently. Benchmark results likewise show degradation at 2,000 clients: 352.1 TPS and 5,535.267 ms average latency, versus 635.7 TPS and 392.554 ms at 250 clients. section 6.3
Prefer throttling application concurrency or introducing application-side latency over flooding the server. When many mostly idle connections are unavoidable, PgBouncer in Transaction Mode can reuse connections across transactions and reduce backend-process overhead. section 6.3 section 6.4.2
