To be clear, this is different to what we do (and why we do it) in TigerBeetle. For example, we never externalize commits without full fsync, to preserve durab

To be clear, this is different to what we do (and why we do it) in TigerBeetle. For example, we never externalize commits without full fsync, to preserve durability [0]. Further, the motivation for why TigerBeetle has both a prepare WAL plus a header WAL is different, not performance (we get performance elsewhere, through batching) but correctness, cf. “Protocol-Aware Recovery for Consensus-Based Storage” [1]. Finally, TigerBeetle's recovery is more intricate, we do all this to survive TigerBeetle's storage fault model. You can read the actual code here [2] and Kyle Kingsbury's Jepsen report on TigerBeetle also provides an excellent overview [3]. [0] https://www.youtube.com/watch?v=tRgvaqpQPwE https://www.youtube.com/watch?v=tRgvaqpQPwE [1] https://www.usenix.org/system/files/conference/fast18/fast18-alagappan.pdf https://www.usenix.org/system/files/conference/fast18/fast18... [2] https://github.com/tigerbeetle/tigerbeetle/blob/main/src/vsr/journal.zig#L1185 https://github.com/tigerbeetle/tigerbeetle/blob/main/src/vsr... [3] https://jepsen.io/analyses/tigerbeetle-0.16.11.pdf https://jepsen.io/analyses/tigerbeetle-0.16.11.pdf