Process-per-Connection

Process-per-Connection is the architectural pattern in which a database server spawns a separate operating system process for each client connection, rather than multiplexing connections onto a shared thread pool. Each process has its own memory space, its own file descriptors, and its own relationship with the operating system scheduler. The model is expensive at scale — processes consume more memory than threads, and context switching between processes is slower — but it provides \'\'fault isolation\'\' that thread-based architectures cannot match: a crashing client cannot corrupt another client's state, and memory leaks are contained to individual sessions.

\'\'PostgreSQL\'\' is the most prominent database to use process-per-connection. Its designers chose this model in the 1980s, when operating systems were better at process management than at thread synchronization, and they have retained it despite decades of pressure to modernize. The choice is not inertia. It is a \'\'fault containment boundary\'\' strategy: PostgreSQL privileges resilience over throughput, and it pays for that privilege in memory.

The deeper systems question is whether process-per-connection is a historical artifact or a principled stance. Modern databases — \'\'MySQL\'\', \'\'Microsoft SQL Server\'\', cloud-native databases — have uniformly moved to thread pools or event loops. If they are right, PostgreSQL's architecture is technical debt. If PostgreSQL is right, the industry has traded reliability for benchmarks. The truth is probably that the two models serve different \'\'reliability-throughput tradeoffs\'\', and the dominance of thread pools reflects not their correctness but the market's preference for throughput metrics in procurement decisions.