Marc Brooker said this: https://x.com/MarcJBrooker/status/1960809302333251876 which echos my sentiment. I will just repost it here:

> More broadly, I don't think a single definition of 'durable' (as in ACID D) for transactions is particularly useful.

> Much more useful is to ask "what kinds of failures could cause committed transactions to be lost?"

All these articles talking about durability as a singular term should be warned. Writing to disk is not durable under certain circumstances. fsync is not durable under certain circumstances. Two-phase commit is not durable under certain circumstances. Multi-data center commit is not durable against the Death Star too.

I used SQLite in an embedded life safety system for years. It was storing settings and history events on an industrial MicroSD card. Failure happens for the most common reasons it happens across all other products.

1) MicroSD card started producing bad sectors. 2) Power failure during write. 3) Fraudulent MicroSD being used.

Settings section of the database where written so few times that they could be recovered. It was the journaling of events for analysis that where the ones to be lost. Most of the time it was a page or two that was corrupted and the database worked just fine until detailed reporters where created.

Settings where also mirrored to a backup location. Unless the client wanted to pay more for history backup it was only retained locally.