If a database snapshot and a checksum are published out to a CDN on a regular interval, you can certainly run UPDATE on a row and publish a new snapshot, but those tracking the integrity of the data will detect the change.

If you are in control of write access to the blockchain, you can roll back to whatever block suits you better, and just fork it. Others might protest, but those fools have no write access, so they're stuck with your fork for the time being.

Blockchain is just a protocol for consensus-based DB replication, you don't somehow magically end up with a superior DB because of that.

You could still use merkle trees it similar technology in your own database and publish checkpoint hashes of the DB every so often

Then it seems like the data being hashed would be serializations of databases rather than sets of transactions. I.e. you would be publishing snapshots of the world rather than agreed-upon changes starting from a pre-agreed on state.

I’ve been curious about this. I’ve thought about it (inspired by event sourcing), but am not familiar with the Blockchain enough to know if it’s feasible from the trust/security side.

At some point you will just be implementing your own half-assed blockchain because you "don't need a blockchain". Why?

Because git is easy and proven and a blockchain is complicated.

They could just publish a git repository. It'd be the same: it's not possible to edit the data without replacing the entire chain [of commits].