The issue I am taking here is the claim of durability
This is the first I'm hearing that the "Durability" in ACID implies protection from data corruption after the fact - please provide a source.
It doesn't imply that. Durability means that corruption to the database will not cause further data loss during subsequent use. For example, if you use a single bit to indicate that a record is deleted, and corruption flips that bit to deleted, and your implementation has no way of noticing the corruption, you have lost data after the corruption. Ideally when a user next accesses that record, they should see an error like "Record corrupt". There is a fun history of corruption and SQLite at https://www.sqlite.org/howtocorrupt.html. Last time I looked, there was a popular fork of SQLite which implements per-row checksumming, but the default build does not (the canonical advice is: "use a proper filing system like ZFS if you don't want bit errors"). But SQLite is very carefully written to check consistency during modifications, and where it can it will refuse to modify data when the metadata doesn't match up. So, a database can be durable and not detect arbitrary damage to user data. It just cannot lose further user data due to corruption of its own structures. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/