A database that loses data on a crash is a file format with extra steps. Ledger's write-ahead log is about 400 lines of Rust, and its whole job is to make sure that after any crash, at any instant, recovery lands on a consistent state.
Every change is written to the log first, with a checksum, before the corresponding page is touched. The commit record is only written after the data records are durable, and the ordering of fsync calls is what actually guarantees that — get it wrong and the log claims a transaction the data never received.
Testing this meant crashing on purpose. A harness kills the process at random points, thousands of times, then reopens the database and checks invariants. A handful of these runs found ordering bugs that no amount of reading could have.
The WAL is small, but it is the part of Ledger I trust the most, because it is the part I tried hardest to break.