PostgreSQL 18 Architecture

PostgreSQL 18.3 (released Feb 26, 2026) keeps the same multi-process, shared-memory architecture it has carried for decades. PG 18 adds two meaningful pieces on top of that foundation: I/O Workers (async read pool) and AIO Submission Rings in shared memory. Everything else is the same model, just better tuned. Here’s a map of all the moving parts. Architecture at a glance Clients Postmaster + Backend Shared Memory Background Processes Disk — PGDATA Client Apps via libpq protocol psql / libpq JDBC (pgjdbc) psycopg3 asyncpg pgx (Go) node-postgres SQLx (Rust) TCP 5432 / unix socket Postmaster postgres — supervisor & listener • Authenticates via pg_hba.conf • fork() a backend per connection • Spawns & restarts auxiliary procs fork() Backend Process one per client connection Parser SQL text → parse tree Analyzer / Rewriter resolves names, applies rules / views Planner / Optimizer cost-based plan selection (uses pg_statistic, GEQO) Executor runs plan tree, returns tuples May spawn parallel workers (max_parallel_workers_per_gather) Reads & writes via Shared Memory → read / write Shared Memory allocated by Postmaster, all backends attach Shared Buffers page cache for tables & indexes shared_buffers = 128MB (default) · recommend ~25% of RAM WAL Buffers in-memory ring of WAL records wal_buffers = 16MB (auto) CLOG · pg_xact cache commit / abort status per xid ProcArray active txns, snapshots, MVCC visibility Lock Tables heavyweight locks + LWLocks SLRU caches subtrans, multixact, notify, serial AIO Submission Rings per-backend rings for async reads postmaster-allocated → lock-free PG 18 Cumulative Stats in shared mem since PG 15 (no collector) ↓ flushed by background processes ↓ ↑ refilled by I/O workers (NEW) ↑ Auxiliary Processes spawned & supervised by postmaster Checkpointer flushes all dirty pages on checkpoint; bounds crash-recovery time Background Writer trickles dirty pages to disk so backends always find clean buffers WAL Writer flushes WAL buffers to pg_wal/ at commit + on interval Autovacuum Launcher spawns workers per database to VACUUM, ANALYZE, freeze xids I/O Workers PG 18 async read pool for shared buffers io_method = worker (default) | io_uring | sync · io_workers=3 Logical Repl Launcher starts apply workers for subscriptions (CREATE SUBSCRIPTION) Archiver copies completed WAL segments when archive_mode = on WAL Sender(s) streams WAL to standby / logical subscriber (one per replica) WAL Receiver on standby only — receives stream + hands to startup proc Startup Process replays WAL on crash recovery / continuous on standby Logger (syslogger) collects stderr from all procs when logging_collector = on → all write to / read from PGDATA PGDATA on-disk cluster base/ heap files, indexes (8 KB pages) pg_wal/ WAL segments (16 MB each) pg_xact/ commit log on disk pg_tblspc/ tablespace symlinks pg_logical/ logical decoding snapshot data pg_replslot/ replication slots pg_multixact/ multi-xact data pg_stat/ persistent stats config files postgresql.conf pg_hba.conf pg_ident.conf postmaster.pid archive/ off-cluster (S3, NFS, etc.) via archive_command → replication stream to standby cluster Query lifecycle 1 client connects → 2 postmaster forks backend → 3 parser/planner/executor → 4 hits Shared Buffers (miss → I/O Workers fetch async) → 5 writes record to WAL Buffers → 6 WAL Writer flushes pg_wal/ on commit → 7 Checkpointer + bgwriter flush dirty pages to base/ Scroll horizontally on small screens to see the full diagram. Components marked PG 18 are new in PostgreSQL 18. ...

May 11, 2026 · 9 min