ALICELIVE MEMORY
Balance
500400
$500 − $100
The question
Changed is not the same as safe.
A running database keeps the balances it is working on in memory. It can turn Alice’s $500 into $400 and Ben’s $200 into $300 almost immediately.
But memory needs power. If the machine goes dark, those new balances can disappear with it.
Before the database says “committed,” it needs a durable way to recreate the transfer. That durable record is the write-ahead log, or WAL.
- Memory
- Where the new balances become visible first.
- The WAL
- Where the transfer becomes recoverable.
- Account pages
- Where the long-term balances catch up later.
First, the balances change in memory
01 · beforeAlice has $500. Ben has $200. The $100 transfer has not begun.
02 · liveThe running database subtracts $100 from Alice and adds it to Ben. In memory, the answer is already $400 and $300.
03 · fragilePull the power now and those live balances vanish. A visible change is not yet a durable promise.
What to watch The money moves and the balances change, but the whole board is still labelled “live memory.” Nothing durable has recorded the outcome yet.
The one rule
Keep a durable note before making the promise.
WAL does not make memory permanent. It writes enough ordered information somewhere durable so the database can rebuild what memory knew.
Change memoryfast · volatile
Make WAL durablerecoverable
Say committedpromise allowed
The WAL crosses the promise boundary
01 · describe the transferThe WAL gets an ordered record: debit Alice, credit Ben, then mark the transfer complete. At this point the records may still be buffered.
02 · make the record durableThe database asks the storage system to preserve the WAL through the completion record. Now a restart can recover the transfer.
03 · make the promiseOnly now may the database reply “committed”—even if the main account page still contains the old balances.
What to watch The acknowledgement appears only after the WAL turns green. “Write ahead” means the durable log must get ahead of the account page—not necessarily ahead of the in-memory change.
Now remove the machine
A crash turns the log into instructions.
After power loss, the database does not trust the vanished memory. It looks at what survived: the durable WAL and the account page.
The answer follows from those two pieces of evidence. There is no guesswork.
Crash at three different moments
01 · crash too earlyThe WAL never durably recorded a completed transfer, so no success was promised. Restart keeps Alice at $500 and Ben at $200.
02 · crash after commitThe new balances vanish from memory, but the durable WAL survives. Recovery replays the $100 transfer and restores $400 and $300.
03 · crash after catch-upThe account page already says $400 and $300. Recovery sees that this transfer is already represented and does not add it twice.
What to watch Blue memory disappears in every case. Before commit there is no durable promise; after commit the green WAL can recreate what the grey account page is missing.
A checkpoint lets the account pages catch up
01 · the log leadsThe transfer is already committed because its durable history can recover it. The account page is allowed to remain behind.
02 · checkpointLater, a checkpoint writes outstanding durable work into the main pages. Alice becomes $400 and Ben becomes $300 there too.
03 · less recovery workOnce long-term state has caught up, recovery can begin later in the history and older log space may eventually be reused.
What to watch The checkpoint moves the account page, not the original promise. Commit made the transfer recoverable earlier; checkpoint reduces how much history a restart must revisit.
Why bother?
The short durable path comes first.
Without this separation, every commit would need to wait for all of its changed data pages to be forced into place. WAL lets the database first preserve a compact, ordered recovery record; pages can be written later and in batches.
Make every destination current before replying.
The promise waits for the changed account pages themselves.
Preserve the route, then let pages follow.
The promise waits for ordered durable history. Checkpoint work can happen afterward.
Sequential log writes and shared flushes are typically cheaper than forcing every changed page for every commit, though the exact performance depends on the database, workload, and storage.
The whole idea
A commit means “I can recover it.”
It does not necessarily mean every account page is already current. It means the database has crossed a durability boundary: enough ordered evidence survives to keep the promise after a crash.
01 · MEMORYChanges the working state quickly.
02 · WALMakes the promised result recoverable.
03 · CHECKPOINTLets long-term pages catch up later.
This is a deliberately small, illustrative model. Real databases differ in record formats, buffering, recovery algorithms, and durability settings. The ordering idea remains: durable evidence must exist before a successful commit is acknowledged.