CRDT (Conflict-free Replicated Data Type)
A CRDT, or Conflict-free Replicated Data Type, is a data structure that multiple devices can update independently and then merge automatically without conflicts. Each replica applies changes locally, and when replicas exchange their states or operations, a defined merge rule guarantees they converge to the same result no matter what order the updates arrive in. CRDTs are a building block for offline-first and collaborative software, where devices edit shared data while disconnected and reconcile later.
How it works
A CRDT is designed so that its merge operation is commutative, associative, and idempotent, meaning updates can arrive in any order, more than once, without breaking convergence. There are two broad families: state-based CRDTs, which ship a whole replica state that is merged with a least-upper-bound function, and operation-based CRDTs, which ship individual operations that every replica applies. Both aim at the same guarantee of strong eventual consistency, where any two replicas that have seen the same set of updates hold the same value.
Common examples include grow-only counters, PN-counters that can decrement, observed-remove sets, and sequence types used for collaborative text editing. Each type encodes enough metadata, such as unique identifiers or version vectors, to resolve concurrent edits deterministically rather than asking a person or a server to pick a winner.
CRDTs solve the merge problem, not the delivery problem. They assume some mechanism carries updates between replicas eventually; they do not themselves move bytes across a radio or a network.
Why it matters
When devices work offline, each one accumulates local changes that must later be reconciled. A naive last-writer-wins approach silently drops edits, and manual conflict resolution does not scale. CRDTs let apps accept writes on every device with no coordination and still guarantee the data ends up consistent, which is why they underpin collaborative editors, local-first note apps, and distributed databases.
The tradeoff is metadata overhead and, for some types, careful garbage collection. In exchange, applications gain availability during partitions and a predictable convergence guarantee that does not depend on a central authority being reachable.
How it relates to Offline Protocol
Offline Protocol ships a CRDT data layer as one primitive, not as a database product. Replicated documents (map, list, text, and counter) merge deterministically after offline edits and travel as compact deltas inside MLS-scoped spaces, over a swappable storage adapter. Documents persist on-device by default and sync frames travel over encrypted MLS (RFC 9420) sessions across the multi-transport mesh, DORS, with automatic failover and multi-hop relay, alongside Ed25519 OfflineID identity and serverless service discovery. There is no query language and no hosted component in this version; a space replicates whole and your cloud remains the system of record.
In other words, the CRDT decides how shared data merges, and Offline Protocol both provides the documents and carries the deltas between devices when there is no internet. For a comparison with a database built around the same merge model, see Offline Protocol vs Ditto. The mesh also uses store-and-forward so updates propagate across intermittent links.
Frequently asked questions
What is a CRDT in simple terms?
A CRDT is a data structure that lets many devices edit the same data offline and then merge their changes automatically, with a rule that guarantees every device ends up with the same result regardless of update order.
Is Offline Protocol a CRDT database?
It ships CRDT replicated documents without being a database product. Map, list, text, and counter documents merge deterministically after offline edits, persist on-device by default, and sit on a swappable storage adapter, with your cloud remaining the system of record. There is no query language and no hosted component, and a device replicates a whole space or only the part it is interested in.
What are CRDTs used for?
They are used for offline-first and collaborative software such as shared text editors, note apps, and distributed databases, where devices must accept writes while disconnected and reconcile without conflicts later.
