CRDTs in Production: A Real World Look
CRDTs, Conflict-Free Replicated Data Types, are data structures designed to support concurrent edits across multiple replicas without coordination. They allow each replica to update independently and converge to the same state. CRDTs are the right tool for real time collaboration, offline first apps, and specific eventual consistency scenarios. They are the wrong tool for almost everything else.
What you actually need to know
- CRDTs fit real time collaboration, offline first sync, and uncoordinated distributed systems.
- They are the wrong tool for almost everything else.
- They grow with edit history. Plan for the growth.
- Yjs is the dominant library for JavaScript.
- The mental model is different from a normal database.
Use case
CRDT fit
Real time document collaboration
Yes, primary fit
Real time canvas collaboration
Yes
Offline first mobile sync
Yes
Multi region eventual consistency for specific data
Sometimes
Standard CRUD operations
No
Transactional data
No
Audit logs
No
Single user app state
No
The core argument
CRDTs are an elegant solution to a specific problem. Two or more users edit the same data at the same time. The system has to merge their changes without losing edits and without requiring a central coordinator. The CRDT solves this mathematically. The merge is associative, commutative, and idempotent. Whatever order the edits arrive, the result is the same.
The cases that need this solution are real but narrow. Real time collaborative editing. Offline first mobile sync. Specific distributed systems that cannot rely on a central coordinator. For these cases the CRDT is often the only sane approach.
The cases that do not need this solution are far more common. A standard B2B SaaS where one user edits at a time. A transactional system where the database handles concurrency. An audit log that is append only by nature. For these, the CRDT is complexity without benefit.
The teams that adopt CRDTs preemptively pay the complexity tax without ever using the capability it buys them. The teams that adopt them for the right problem get something hard to replicate any other way. The discipline is recognizing when the problem actually fits.
The shape of the problem CRDTs solve
Symptom
CRDT relevant?
Two users editing the same document at the same time
Yes
User edits a document offline, syncs later
Yes
Two services updating the same record without coordination
Sometimes
Backend writes that need to be merged across regions
Sometimes
Standard CRUD with row level locking
No
Append only event log
No
Single user state
No
How much does this cost
Aspect
Cost
Library learning
A few weeks for a senior engineer
Initial implementation
One to two sprints per surface
Garbage collection design
One sprint
Storage growth
Real for long lived documents
Operational complexity
Real for any production CRDT
Features the CRDT implementation must have
- A clear use case that requires concurrent uncoordinated edits.
- A library suited to the data type (Yjs, Automerge).
- A garbage collection strategy.
- A migration path if the data outgrows the CRDT.
- Persistence that scales with the data size.
- Observability on growth.
- A clear contract with the rest of the application.
Expert opinion
CRDTs are one of those technologies that fit some problems exquisitely and fit most problems badly. The teams that have a real time collaborative editing problem reach for them and are right. The teams that adopt them because they read about them and want to use them are usually wrong. The complexity is real. The benefit is real only when the problem matches. The honest evaluation matters more than the technical depth.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A client was building a real time collaborative whiteboard. Multiple users would draw, write, and edit shapes on the same canvas at the same time. The team had started with a server side state with locks and was struggling with the user experience.
We migrated the state to Yjs. The canvas synchronized across users in real time without the lock contention. Edits flowed naturally. The user experience improved dramatically. The complexity of the implementation was real but worth it for this specific case.
A different client wanted CRDTs for their standard B2B SaaS data model. There was no real concurrent editing. The CRDT would have been overkill. We talked them out of it. The simpler database approach shipped in weeks instead of months.
For more on the related work, see Liveblocks vs PartyKit vs custom for real time features and eventual consistency in plain language for founders.
Common mistakes teams make
- Adopting CRDTs for problems that do not need concurrent uncoordinated edits.
- Underestimating the growth of CRDT state over time.
- No garbage collection strategy.
- No migration path.
- Treating CRDTs as a general purpose database replacement.
- Skipping the learning investment. Quick CRDT work goes wrong.
- No observability on growth.
- Treating Yjs as the right answer regardless of problem shape.
A decision framework
- Step one. Identify the specific problem. Concurrent editing? Offline first? Distributed without coordination?
- Step two. Confirm the standard database approach cannot handle it.
- Step three. Pick the CRDT library suited to the data shape.
- Step four. Plan for garbage collection and growth.
- Step five. Pilot on one surface before adopting broadly.
For more on the related work, read Liveblocks vs PartyKit vs custom for real time features and event driven architectures when they help and when they hurt. On the broader collaboration side, offline first mobile apps a reality check is the natural next read.
FAQ
Frequently asked
- What is a CRDT in plain terms?
- When does a CRDT actually fit?
- What are the costs?
- What is Yjs?
- What is the alternative to a CRDT?
- What is the most common CRDT mistake?
- How big do CRDTs get?
Author
Why Yashveer Singh is the call for this work
I have spent the last four years writing software that runs in production. Three live client sites. A Roblox game with real players. Nexli, a school management system about to launch into private testing. Nyxera, a fully local AI assistant. Most people writing about this topic are summarizing other people's blog posts. I am writing from the codebase. If you want this kind of work done right, I am the person you call. Yashveer Singh, founder of Yashveer Labs.