Panoramica dell'architettura di PostgreSQL

To master PostgreSQL performance, you need its architecture — the processes, memory, and storage that work together to serve your data.

PostgreSQL's architecture splits into three areas: processes that run the work, memory structures for fast access, and storage that persists data to disk.

The Postmaster is PostgreSQL's central parent process. It listens for client connections and spawns a dedicated backend process for each one.

Each connection gets its own backend process handling all of that client's queries — isolation so one client's work doesn't trip up another's.

Several background workers handle upkeep: the WAL Writer flushes the log, Autovacuum cleans dead tuples, and the Checkpointer writes dirty pages to disk.

Shared Buffers is the shared memory cache for frequently used disk blocks. Bigger cuts disk I/O, but too big wastes memory or triggers OS swapping. Check it below.

work_mem is private memory per backend for sorting, hashing, and merging. Exceed it and the operation spills to disk, slowing the query. Check it below.

Every change hits the Write-Ahead Log (WAL) before the data files — that's what guarantees durability and crash recovery. The query below shows the current WAL LSN.

A query's journey: the Postmaster spawns a backend, which uses shared buffers and work_mem to process data, writes changes to the WAL, then returns results.

Which PostgreSQL process is responsible for listening for client connections and spawning new backend processes?

Recap: PostgreSQL's architecture is processes (Postmaster, backends, workers), memory (shared buffers, work_mem), and storage (data files plus the WAL).