Immutability indeed gives a lot of features to a data store, because nothing ever can go invalid. Doing anything in parallel is trivial. Caching anything is totally safe. Distributed queries can be certain that the other side did not change during a distributed transaction.

The cost of it, AFAICT, is either unbounded growth, or garbage collection, if deletion is even supported.

There are use case for a DB like that, but, unfortunately, it cannot replace most OLTP use cases.

▲

layer8 18 hours ago | parent [-]

It’s also inapplicable for anything with sensitive data that has legally limited retention periods or the “right to erasure”.

▲

nine_k 17 hours ago | parent [-]

Why, no, deletion is possible in immutable structures, as long as nothing else references the deleted nodes. This is literally how lists / trees / any complex structures work in Haskell (and apparently in Clojure): a mutation gives you a new immutable structure, but the old immutable structure (or parts thereof) can be forgotten and disposed of.

	▲	layer8 17 hours ago \| parent [-]
		It’s very common, however, that data will reference the data to be deleted, or be derived from it in a way that will become invalid when it’s deleted. Parallel processing becomes less straightforward because you have to make sure that all parallel processes see a consistent state of the deletion. Depending on the nature of the data to be deleted, you may actually have potential mutation, if there are keys that are sensitive data.