Relational database engines serve concurrent client sessions with a process per connection, a thread per connection, or a pool of worker threads. Compare these architectures and their practical consequences.

## The problem being solved A database server must serve many concurrent sessions, each with its own authenticated identity, transaction, and workspace memory. How the engine maps a session onto an operating system execution unit is one of the oldest architectural choices in the field, and it leaks directly into how applications must be built. ## Process per connection The server's listener accepts a connection and forks a dedicated OS process to serve it. Each backend has its own address space and private memory for parsing, plan caching, sorting, and hashing; shared data such as the buffer pool lives in shared memory that all backends map. *Advantages*: hard isolation. A backend that crashes or corrupts its own heap is killed without taking the whole server down (the engine typically still recycles other sessions defensively after a crash, to be safe about shared memory). It also makes the engine's own code simpler - much of it can assume single-threaded execution. *Costs*: process creation is relatively expensive, and each session carries several megabytes of private memory that is never shared. Kernel scheduling and TLB pressure grow with process count. This is why such engines list connection limits in the hundreds and treat external pooling as a deployment requirement rather than an optimisation. ## Thread per connection One server process, one thread per session. Thread creation is cheaper than fork, and per-session memory is smaller because code, plan structures, and caches can be shared inside one address space. Engines usually add a thread cache so disconnect/reconnect cycles reuse threads instead of destroying them. *Advantages*: higher connection counts (thousands) with less memory per session; shared caches are trivially accessible. *Costs*: no isolation - a bug that corrupts memory in one session can take down the whole server. All shared state needs locks or atomics, so contention becomes the scaling limit. Per-session buffers (sort, join, temp) are still allocated per thread, so a high connection count with heavy queries can still exhaust memory. ## Worker / thread pool multiplexing Here the number of connections is deliberately decoupled from the number of executing threads. Sessions submit work items; a bounded set of workers picks them up. Some engines run their own user-mode scheduler that treats a query's blocking points as yield points. *Advantages*: overload becomes queueing rather than thrashing. Ten thousand mostly idle connections do not translate into ten thousand runnable threads competing for CPU. Throughput stays flat instead of collapsing past the knee of the curve. *Costs*: real complexity. Session-scoped state (open transactions, temp objects, session variables) must be tracked and rebound to whichever worker resumes the session, and any operation that blocks a worker for a long time - a long-running transaction, a lock wait, an external call - can starve queued sessions. Some engines therefore refuse to multiplex sessions with open transactions. ## Why this matters to application developers The model sets the price of a connection, which determines your architecture. On a process-per-connection engine, an application that opens hundreds of connections per instance is a production incident waiting to happen; pooling is not optional. On a thread-per-connection engine you have more headroom but the same qualitative limit, because per-session sort and join buffers still multiply. Under a worker pool the per-connection cost is lowest, but you inherit rules about what a session may do while multiplexed. A useful mental model: **connections are not concurrency.** Useful concurrency is bounded by CPU cores and storage parallelism regardless of the model; the architecture only decides how gracefully the server degrades when connections exceed that bound. ## Direction of travel Engines historically built on process per connection have been moving toward built-in multiplexing precisely because the operational burden of external pooling is high, while thread-per-connection engines have added optional thread pools for the same overload reasons. The trade-off never disappears - it is isolation and simplicity against density.