If you can trust your writers there's likely no need for this. A modern approach tends to have databases owned by a single service, which exposes the model via

If you can trust your writers there's likely no need for this. A modern approach tends to have databases owned by a single service, which exposes the model via RPCs. So you generally don't have more than one writer, which means you're pretty much de-facto "zero trust" if that single writer follows a few rules (ie: mutual auth, logging, etc). But in some cases you don't have that same constraint. For example, databases that store logs (Elastic, Splunk, etc) might have many readers and writers, including humans. In that case enforced immutability might be a nice property to have. Attackers who get access to your Splunk/ES cluster certainly will have fun with it.