Write-Ahead Logging

Write-Ahead Logging (WAL) is the durability mechanism by which a database system ensures that committed transactions survive crashes, not by writing data files immediately but by writing a sequential log of changes first. The log is append-only, ordered, and fsync'd to disk before the corresponding data page is modified — a sequence that guarantees that the database can always recover to a consistent state by replaying the log, even if the data files were partially written when the system failed. WAL is not merely an implementation detail; it is the \'\'immune system\'\' of transactional databases, the boundary between volatile memory and persistent truth.

The WAL pattern appears across database architectures — in \'\'PostgreSQL\'\', in MySQL\'\'s InnoDB redo log, in SQLite\'\'s journal — but its most interesting systems consequence is that the log becomes a \'\'public interface\'\'. Change data capture, streaming replication, and event sourcing all consume the WAL as a source of truth about what happened and in what order. The WAL transforms a database from a passive store into an active participant in a distributed data pipeline.

WAL's fundamental trade-off is latency for durability: every commit waits for disk I/O, and the faster the disk, the lower the latency. But the deeper systems question is whether the WAL should be treated as an internal implementation or as a \'\'stable storage interface\'\' that other systems can depend on. PostgreSQL treats it as both; most cloud-managed databases treat it as neither, hiding the WAL behind proprietary replication protocols that lock users into the platform.