Besides the processes serving client connections, a relational database server runs several dedicated background processes. Name the main ones and say what each is responsible for.

## Two kinds of work A database server does two very different things. It answers queries — parse, plan, execute, return rows — and it maintains itself: getting data onto durable storage, keeping memory usable, reclaiming space, keeping the planner informed. The first is inherently per-connection. The second is shared, periodic, and I/O-bound. So engines split them. Each client connection is handled by its own server process or thread (a *backend*), and the maintenance work lives in a small set of long-lived background processes started with the instance. Names differ per engine; the roles are near-universal. ## The roster **Log writer (WAL writer).** Every change is first described in the transaction log. Backends write log records into a shared buffer; the log writer pushes those buffers to disk and issues the durability call. A committing transaction still needs its own commit record durable before it can report success, but much of the log has usually been flushed already, so the commit finds less work to do. Group-commit behaviour lives here: many commits share one flush. **Background writer.** Data pages live in a shared buffer pool. Modifying a row dirties its page in memory; the page is not written immediately. If nothing wrote dirty pages in the background, a query that needs to load a page and finds only dirty candidates would have to write one out itself — foreground I/O in the middle of a user query. The background writer trickles dirty pages out ahead of demand so evictions usually find clean buffers. **Checkpointer.** A checkpoint establishes a point from which recovery can start: all changes before it are guaranteed on disk, so log before it need not be replayed (and can be recycled). The checkpointer performs that sweep on a schedule or after a volume of log, ideally spreading the writes over the interval rather than dumping them at once. **Statistics collection / auto-analyze.** The optimizer chooses plans from statistics: row counts, value distributions, correlations. A background component accumulates activity counters and triggers sampling of tables whose contents have changed materially, so plans track reality without anyone running a manual command. **Vacuum / purge daemon.** Under multi-version concurrency, updates and deletes leave older row versions behind. A daemon finds versions no transaction can still need and makes their space reusable, alongside related housekeeping. It is deliberately throttled so maintenance does not swamp the user workload. **Supporting cast.** A supervisor/monitor process starts the others and restarts the instance if one dies unexpectedly; an archiver copies completed log segments for backup and point-in-time recovery; replication senders stream log to replicas and appliers replay it; some engines have a dedicated error-log collector, a job scheduler, and a pool of generic worker processes that parallel queries borrow. ## Why this division exists Three reasons. 1. **Latency.** Users feel foreground I/O. Moving flushing off the query path turns a per-query cost into a background one. 2. **Amortisation.** Writing one page per transaction is far more expensive than writing a batch of pages once, and one log flush can commit many transactions at once. Background processes exist to batch. 3. **Global scope.** Choosing which pages to evict, when to checkpoint, or which table needs fresh statistics requires an instance-wide view no single connection has. ## What follows for practitioners When these processes fall behind, the work does not vanish — it reappears on the query path. Backends start writing their own dirty pages, commits wait on log flushes, plans go stale, dead versions accumulate and scans get slower. That is why background-process metrics are read as an early-warning system: the interesting number is not how busy they are, but how often a *foreground* session had to do their job instead.