Tom Lane on the Architectural Decisions That Shaped 30 Years of Postgres

Back to Devoured - September 10, 2026

DEVOURED

Tom Lane on the Architectural Decisions That Shaped 30 Years of Postgres

Data databasepostgresql Snowflake

Tom Lane reflects on three decades of Postgres, citing the process-per-connection model and MVCC as the primary drivers of the project's long-term success.

What: Tom Lane, a Postgres committer for 25 years, identifies the write-ahead logging implementation in version 8.0 and the background vacuum process as critical architectural milestones. He notes that version 13 was the most unstable release and suggests that the introduction of partitioning was a regrettable design decision.

Why it matters: The stability of Postgres over 30 years demonstrates how conservative architectural choices, such as process isolation and flexible licensing, can protect a complex codebase from the obsolescence that often plagues competing systems.

Deep dive

Process-per-connection: The core architectural choice to spawn a new process for each client, ensuring crash isolation at the cost of higher memory overhead.
MVCC (Multi-Version Concurrency Control): The technique allowing multiple transactions to see a consistent snapshot of the database, necessitating background 'vacuum' tasks to clean up dead rows.
Write-Ahead Logging (WAL): The critical addition in version 8.0 that ensured atomicity and durability, turning Postgres from a research project into an enterprise-ready database.
Berkeley License: The liberal licensing model that prevented the project from being siloed and encouraged wide adoption.
Partitioning: Cited by Lane as a complex addition that added significant maintenance burden and codebase complexity.

Decoder

MVCC: A database design technique that stores multiple versions of a data row, allowing readers to access a consistent snapshot without locking out writers.
Write-Ahead Logging (WAL): A protocol where all changes to the database state are recorded in a log file before the changes are committed to the actual data pages, ensuring recovery after a crash.
Vacuuming: A maintenance process in Postgres that removes dead tuples (rows marked as deleted) to reclaim space and prevent table bloat.

Original article

Tom Lane, a committer for 25 of Postgres' 30 years, walks through the architectural bets that held: process-per-connection for code simplicity, write-ahead logging in 8.0 that turned it from a plaything into a serious database, and MVCC pushing maintenance work into background vacuum. He credits Berkeley's liberal license for the project surviving where its contemporaries did not, names version 13 the buggiest release, and says he would delete partitioning given the chance.

Explore all 54 articles in today's digest