>1) You don't really ever delete ANYTHING. As a matter of fact, you don't update anything either... It's a good article but it has the common shortcoming of l

>1) You don't really ever delete ANYTHING. As a matter of fact, you don't update anything either... It's a good article but it has the common shortcoming of leaving out tradeoffs. Append-only architecture: a) requires more disk space b) can have slower performance: e.g. double writes of (1) to the immutable log and (2) summary cache -- and both operations must be sync'd in a transaction ... or other option of skipping the writes to the summary cache which means all subsequent reads must "re-materialize" what the "current" data looks like by re-applying history of deltas repeatedly For some domains like financial accounting, those tradeoffs are immaterial and you absolutely need immutable history for auditing and system debugging. However, for other purposes (e.g. os filesystems like NTFS), the better tradeoff is to mutate data in-place and forego history to save diskspace. (E.g., You want to modify 2 terabytes of data on completely full 8 TB harddrive that only has 100 MB free.) The tradeoffs are why many database engines offer a "generate no rollback log" option for bulk update commands. The opposite example is bolting on a "history log" on top of a mutate-in-place file system -- which is what Mac OSX "Time Machine" backups do.