PostgreSQL Architecture Overview
PostgreSQL is a client-server relational database system where a single postmaster process supervises a cluster, spawns a dedicated backend process per client connection, and coordinates shared memory structures so that many concurrent sessions can read and write the same data files safely. Unlike a monolithic engine, PostgreSQL's architecture separates process management, buffer caching, logging, and storage into distinct subsystems that communicate through well-defined interfaces, which is why it can be extended with new data types, index methods, and foreign data wrappers without rewriting the core.
Cricket analogy: Think of the postmaster as the match umpire who never bats but assigns a fresh player (backend process) to every over, coordinating between bowlers and fielders so the game state stays consistent across the whole innings.
Process Model: Postmaster and Backends
When a client connects, the postmaster forks a new backend process (not a thread) dedicated exclusively to that session for its entire lifetime; this process-per-connection model means a crashing backend cannot directly corrupt another session's memory, but it also makes connection setup relatively expensive, which is why production deployments typically front PostgreSQL with a connection pooler such as PgBouncer. Alongside client backends, the postmaster also launches a fixed set of background processes -- the background writer, checkpointer, WAL writer, autovacuum launcher, and stats collector -- each with a narrow, well-defined job.
Cricket analogy: Each new batsman walking in gets their own scorecard entry (backend process) that's fully isolated -- if one batsman gets run out, it doesn't erase the runs already logged for teammates, unlike sharing one shaky notebook.
Shared Memory and Buffers
All backend processes attach to a shared memory segment sized primarily by the shared_buffers setting, which caches recently accessed table and index pages so repeated reads avoid disk I/O; when a page isn't cached, PostgreSQL reads it from the operating system's own page cache or the disk, meaning effective memory usage is a two-tier system of PostgreSQL's shared buffers plus the OS cache. Dirty pages are not written back to disk immediately -- the background writer trickles them out gradually and the checkpointer flushes all dirty buffers at checkpoint boundaries to bound crash-recovery time.
Cricket analogy: Shared buffers are like the players' shared dressing-room whiteboard with the latest field placements -- everyone reads from it instead of jogging to the pavilion office every time, but the office (disk) still holds the master copy.
-- Inspect key architecture-related settings
SHOW shared_buffers;
SHOW max_connections;
SHOW wal_level;
-- See background processes actively running
SELECT pid, backend_type, state
FROM pg_stat_activity
WHERE backend_type <> 'client backend';
-- Check current checkpoint activity
SELECT * FROM pg_stat_bgwriter;A common tuning starting point is shared_buffers around 25% of system RAM, leaving the rest for the OS page cache, work_mem, and per-connection overhead -- setting it too high can starve the OS cache and paradoxically hurt performance.
WAL and Durability
Every change to a table or index is first recorded in the write-ahead log (WAL) before the corresponding data page is modified in shared buffers, and only after the WAL record is durably flushed to disk does PostgreSQL consider the transaction committed -- this is the core mechanism that guarantees the D (durability) in ACID. Because WAL records are appended sequentially, they're cheap to write even on spinning disks, and they double as the basis for streaming replication and point-in-time recovery, since replaying the same WAL stream on a standby reproduces the exact same data changes.
Cricket analogy: WAL is like the official scorer jotting every ball down in the scorebook the instant it happens, before the electronic scoreboard even updates -- if the scoreboard crashes, the scorebook alone can rebuild the true match state.
Setting fsync = off or synchronous_commit = off in a misguided attempt to speed up writes can leave the database unable to guarantee crash recovery -- fsync should never be disabled on a system holding data you care about, even in staging environments that feed production decisions.
MVCC and the Storage Layer
PostgreSQL implements Multi-Version Concurrency Control by never overwriting a row in place: an UPDATE creates a new row version (tuple) with a new xmax/xmin transaction ID range while the old version remains until no active transaction can still see it, at which point VACUUM reclaims the space. This design lets readers never block writers and writers never block readers, since each transaction simply sees the row versions visible as of its own snapshot, but it also means table and index bloat is a natural byproduct that autovacuum must continuously manage.
Cricket analogy: MVCC is like a scorecard that never erases a wrong entry -- instead it appends a corrected line with a new timestamp, so anyone reviewing the match at an earlier point in time still sees the version that was valid then.
- PostgreSQL uses a process-per-connection model supervised by a postmaster, not a threaded architecture.
- Background processes like the checkpointer, background writer, and autovacuum launcher each handle a narrow responsibility.
- Shared buffers cache hot pages in memory, backed by a second tier of OS page cache before hitting disk.
- The write-ahead log (WAL) is flushed before a transaction is considered committed, guaranteeing durability.
- WAL also powers streaming replication and point-in-time recovery by replaying the same change stream elsewhere.
- MVCC avoids in-place updates, letting readers and writers avoid blocking each other at the cost of needing regular VACUUM.
- Never disable fsync on any environment whose data integrity matters.
Practice what you learned
1. What does PostgreSQL create for each new client connection?
2. Why must a WAL record be flushed to disk before a transaction is considered committed?
3. What happens to an old row version after an UPDATE under MVCC, before VACUUM runs?
4. Which background process flushes all dirty shared buffers at defined intervals to bound crash-recovery time?
5. Why is disabling fsync considered dangerous?
Was this page helpful?
You May Also Like
Data Types in Depth
A practical deep dive into PostgreSQL's rich type system, covering numeric precision, text vs. varchar, JSONB, arrays, and enum/domain types.
Constraints in Depth
A thorough look at PostgreSQL's constraint types -- PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE, NOT NULL, and EXCLUDE -- and how they enforce data integrity at the database layer.
Views and Materialized Views
How PostgreSQL views provide reusable query abstractions and how materialized views trade freshness for read performance by persisting query results to disk.