Skip to content
Optimal Lab

Databases · interactive

The write-ahead log

A transaction moves $50 from A to B and commits. Then the power goes out before the changed pages reach disk. Does the money survive? The rule: write what you're about to do to a log first.

Memory (buffer pool)

A=100 · B=0

Write-ahead log

  • empty

Data files on disk

A=100 · B=0

money on disk: 100

A has 100, B has 0, on disk and in memory.

Database

step 1 of 7

Step 1 of 4

  1. 1

    Changes happen in memory

    Writing whole pages to random places on disk for every commit would be far too slow.

    Dirty pages are flushed later.

  2. 2

    Append to the log, fsync, then commit

    A small sequential write that describes the change. Once it's on disk, the commit is durable.

    synchronous_commit = on

  3. 3

    Recovery replays the log

    Redo every committed change not yet in the data files; undo anything uncommitted. Checkpoints limit how far back it must go.

    ARIES is the classic algorithm.

  4. 4

    The log feeds everything else

    Replicas apply it, point-in-time restore replays it, and change data capture streams it to other systems.

    Postgres WAL, MySQL redo/binlog.

In production

Tools and technologies

Every durable database writes a log before data pages.

Not tied to one language — use these names when you search docs or design a system.