How Does a Database Survive Losing Power Mid-Write? It Wrote Down the Plan First
By the BrainSnail editorial team. How these articles are written and checked, and how to tell us when one is wrong.
Recording what is about to change before changing it is the single idea that lets a system be interrupted at any instant and still come back consistent.
The problem being solved
Updating stored data usually means changing several separate things that must all happen or none of them, such as subtracting from one account and adding to another. A machine losing power partway through leaves some changes applied and some not, which is a corrupted state that may be impossible to detect afterwards. Writing more carefully does not help, because there is always an instant between two writes at which the power can fail. The problem is not about speed or care but about the absence of any way to make several separate writes happen as one.
How the technique works
The order of operations is the entire mechanism:
- •Record the intended change in a sequential log first
- •Force that record to durable storage and wait for confirmation
- •Only then apply the change to the data itself
- •On restart, read the log and reapply anything unfinished
- •Discard any record of a transaction that never committed
- •Trim the log once its changes are safely written
Why it is also faster
A counterintuitive benefit is that writing everything twice ends up quicker than writing it once. The log is appended sequentially, which is the fastest possible access pattern on both spinning disks and flash storage, whereas the data itself lives scattered across many locations and updating it involves slow random access. Committing a transaction therefore requires only one fast sequential write to be durable, and the slow scattered updates can be batched, reordered and written later when convenient. Several unrelated changes to the same page can be combined into a single write rather than performed separately.
What durable actually means
The whole guarantee rests on being able to force a write all the way to storage, and that turns out to be the hardest part in practice. Operating systems buffer writes in memory and report success before anything has reached the device. Drives have their own caches and some have historically reported a write complete while it was still volatile. A specific instruction exists to demand a genuine flush, and systems that skip it for speed are fast until the power fails. Several widely used databases have shipped bugs in exactly this area, and the failures only appear during real power loss.
Where else the pattern appears
The idea is far broader than databases and recognising it explains several unrelated technologies. Journalling file systems use exactly this approach, which is why a modern computer no longer spends minutes checking its disk after a crash. Distributed systems replicate the log itself rather than the data, since replaying an identical sequence of records on every machine guarantees they agree. Event sourcing treats the log as the authoritative record and the data as a derived view that can be rebuilt at any time. Streaming platforms are logs offered as a product. In each case the ordered record comes first and the state is a consequence.
The takeaway
Recording an intended change durably before applying it means an interrupted system can replay unfinished work or discard it on restart, which makes several separate writes behave as one. Appending to a sequential log is also faster than scattered updates, so the scattered writes can be batched later. Journalling file systems, replication and event sourcing are the same pattern.