CRDT vs OT: How Real-Time Collaboration Works
TL;DR
CRDTs and OT both enable real-time co-editing; CRDTs merge conflict-free without a central server while OT transforms operations. Here is the breakdown.
CRDTs (Conflict-Free Replicated Data Types) and OT (Operational Transformation) are the two algorithm families that power real-time collaborative editing. Both let multiple users edit the same document and converge to the same state. They differ in how they reach convergence. I chose CRDTs for LetX. Here is the trade-off explained.
What problem does each solve
You have two users editing the same document. They each make a change at the same logical time. How do you merge?
OT and CRDT are both correct answers. The right one depends on whether you can guarantee a central server, what latency you accept, and how complex your data type is.
OT in 60 seconds
OT works by transforming operations based on others that happened concurrently. Two edits at the same position get re-numbered by a central transform function so the final state matches at every replica.
User A: insert "x" at position 5
User B: insert "y" at position 5 (concurrently)
Server: transform B's op to "insert at position 6"
Google Docs uses OT.
Pros: small ops on the wire, well-understood algorithm. Cons: needs a central transformer; offline work and peer-to-peer merge are painful.
CRDT in 60 seconds
CRDTs use a data type where every operation is idempotent and commutative. Two replicas can apply operations in any order and still converge. No central transformer required.
Yjs (the CRDT library LetX uses) tags every character with a unique identifier; deletions become tombstones; merges are set unions.
Pros: works offline, peer-to-peer, no central server required. Cons: ops carry more metadata; document size grows over time without GC.
When to pick which
| Use case | Pick |
|---|---|
| Central server, low offline use | OT |
| Offline-first, p2p, mobile | CRDT |
| Small docs, low edit volume | Either |
| Massive docs, long history | OT (smaller ops) |
| Conflict-free guarantee critical | CRDT |
Why LetX uses CRDTs
LetX is offline-first. A researcher on a flight should keep writing; the merge happens when they land. That requirement makes CRDTs the only sane choice — see Building LetX for the full architecture.
The pitfall everyone hits with CRDTs
Document size grows. Every tombstone is data. Yjs and Automerge both ship GC, but you have to schedule it. Skip GC and a year-old shared doc balloons to megabytes of metadata.
The pitfall everyone hits with OT
You cannot ship "edit offline, sync later" without huge complexity. Once a user's local op is N transformations behind the server, the transform graph gets ugly fast.
What to read next
Marc Shapiro's CRDT paper, the Yjs internals docs, Google's OT paper. All are accessible; CRDT especially has good intro material in 2026.
FAQ
Q: Are CRDTs always larger on the wire than OT? A: Per-op, yes — they carry more metadata. Over time, OT needs a transform server while CRDTs do not, so total system cost is comparable.
Q: Can you mix CRDTs and OT? A: Yes, some systems use CRDT for offline + OT for online. Most don't because the complexity is high.
Q: Which is faster? A: Depends on document size and edit pattern. For typical real-time collab, both are sub-frame latency.
Written by Shihab Shahriar Antor. Builder of LetX, real-time collaborative LaTeX. Hire me.
Written by
Shihab Shahriar Antor — AI Engineer & Founder of Shahriar Labs. Creator of LetX, QuantumSketch, and more.