[josephg]

The one “downside” compared to regular databases is that CRDTs use optimistic concurrency. If you want transaction support, or want multiple writers to block each other, CRDTs are a bad fit. They move conflict resolution to the point when reads happen rather than make writers fetch and retry.

Still fine for a lot of use cases though.

[fauigerzigerk]

>The one “downside” compared to regular databases is that CRDTs use optimistic concurrency.

My understanding of the term "optimistic concurrency" is that a write operation can fail if the optimism turns out to be misplaced (so to speak). CRDTs on the other hand always merge deterministically and never fail, even if application level consistency constraints are violated.

This is why CRDTs are rarely useful to me, but I can see how they may be useful in domains that can live with the very weak form of consistency guarantees that CRDTs can provide.

[filleokus]

> even if application level consistency constraints are violated.

I think, in theory at least, it should be possible to encode the application level constrains into the CRDT merging algorithm. Like how two edits making different (but overlapping) spans bold are fine to merge into one bold span, but i.e highlighting with different colors are not.

Of course the merge will never be "perfect", as it is impossible to encode all human wishes into the CRDT, but I think there is a lot of room to improve when it comes to merging non-text data.

[fauigerzigerk]

I don't think it is theoretically possible, but even if it was, it would be tantamount to inventing one or more new CRDTs per application. Each begin/end transaction block would become its own research project.