| 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 [1] https://www.usenix.org/system/files/conference/fast18/fast18... [2] https://github.com/tigerbeetle/tigerbeetle/blob/main/src/vsr... [3] https://jepsen.io/analyses/tigerbeetle-0.16.11.pdf |