A Backend Per Client
When a client connects, the database assigns a server side backend to handle its session. Designs differ in how that backend is implemented.
Process Versus Thread
- A process per connection model forks a separate OS process for each client. It is robust because a crash is isolated, but processes are heavier to create and consume more memory.
- A thread per connection model uses lightweight threads inside one process, cheaper to spawn but sharing a fault domain.
Either way, shared structures like the buffer pool and lock table live in shared memory that all backends access under careful synchronization.
Why Pooling Matters
Creating a backend is expensive, and thousands of idle connections waste memory. A connection pool keeps a bounded set of reusable backends so application threads borrow and return them, smoothing spikes and capping concurrency.
Key idea
A database serves each session with a backend that is a process or a thread sharing buffer pool and lock memory, and connection pooling reuses backends to cap concurrency and avoid costly setup.