Two people edit the same document while offline. Both come back online. Something has to decide what the document now says, and the traditional answer is a server that receives both versions and resolves the conflict — by picking one, by asking a human, or by a merge algorithm.
CRDTs remove the need for that arbiter. The data structures are designed so that applying concurrent changes in any order produces the same final state, mathematically guaranteed.
What changed in 2026
- Library maturity improved substantially. Production-ready implementations for text, lists, and maps reduced the amount teams needed to build themselves.
- Metadata overhead shrank. Compression and garbage collection techniques cut the historical metadata that made early CRDTs impractical for large documents.
- Local-first architecture gained traction. Applications treating the local replica as authoritative and sync as a background concern became a recognized category.
- The intent-preservation gap stayed. Recognition that convergence does not mean the merged result is what users wanted remained the honest limitation.
What the guarantee actually is
| Property |
Guaranteed |
| All replicas converge to the same state |
Yes |
| No coordination required to merge |
Yes |
| Merges are order-independent |
Yes |
| Works offline indefinitely |
Yes |
| The merged result preserves user intent |
No |
| Application invariants are maintained |
No |
The last two rows are where expectations break. If two people concurrently edit a sentence, a text CRDT will produce a deterministic merge that both replicas agree on — and that merge may be a garbled interleaving of both edits that neither person wanted. Convergence is a consistency property, not a semantic one.
Similarly, if your application requires that a total never exceeds a limit, concurrent increments on separate replicas can converge to a value that violates it. CRDTs guarantee agreement about the number, not that the number is allowed.
When they are worth it
The clear case is collaborative editing where users need to work offline and merge later without a server deciding. Document editors, note-taking applications, and design tools with offline support are where CRDTs earn their complexity.
The other case is peer-to-peer or partition-tolerant systems where no central arbiter exists or can be reached. If replicas must merge without coordination, this is the mechanism.
The case against is that most applications have a server, and a server can arbitrate. Last-write-wins with a timestamp, or operational transformation with a central sequencer, or simply locking, are all simpler and adequate when a central authority exists. Adopting CRDTs because they sound principled, in a system with a perfectly good server, buys metadata overhead and conceptual complexity for a problem you did not have.
Storage overhead remains real even with modern compaction. The structures carry information about the history of operations to make order-independent merging possible, and for a long-lived frequently-edited document that accumulates.
Common mistakes
- Expecting intent preservation. Convergence is agreement, not correctness.
- Using them where a server can arbitrate. Simpler options exist.
- Ignoring metadata growth. Long-lived documents accumulate; plan compaction.
- Assuming invariants hold across replicas. They do not.
- Building your own. The correctness proofs are subtle; use a mature library.
- Applying them to the whole application state. Use them for the collaborative parts only.
FAQ
How do they compare to operational transformation?
Operational transformation transforms operations against each other and typically needs a central sequencer. CRDTs need no coordination and carry more metadata. Both are used in production editors.
Can they handle rich text?
Yes, with more complexity than plain text — formatting spans interact with concurrent insertions in ways that need careful design.
Do they work with a database?
The CRDT is the merge logic; storage is separate. Many implementations persist state and sync deltas.
What about deletions?
Deletions typically leave tombstones so concurrent operations referencing the deleted element still merge correctly. Garbage collecting tombstones safely is one of the harder parts.
Where to go next
For ordering in distributed systems, read vector clocks explained. For coordinated multi-step operations, saga pattern explained.