CRDT Explained: Complete Guide to Conflict-Free Replicated Data Types (September 2025)
Real-time collaboration is no longer a “nice to have,” users expect it in chat apps, design tools, and even form builders. CRDTs (conflict-free replicated data types) are one of the most powerful ways to make this possible, merging concurrent edits automatically and keeping every user in sync.
In this post, we'll break down how CRDTs work, the trade-offs between different approaches, and the libraries you can use to build collaborative features. If you’d rather skip the complexity and get started quickly, Velt provides a production-ready collaboration layer you can drop into your app.
TLDR:
CRDTs automatically merge concurrent edits without conflicts, powering live document collaboration
State-based CRDTs share complete data while operation-based CRDTs broadcast just the changes
Yjs and Automerge are the leading CRDT libraries for JavaScript applications
CRDTs excel in offline-first and decentralized apps, while OT remains common in large-scale text editors where preserving exact user intent is critical
Velt provides production-ready CRDT implementation with as little as 10 lines of code integration
What Are CRDTs?
Conflict-Free Replicated Data Types (CRDTs) are specialized data structures designed to work across multiple computers or devices without requiring constant coordination between them. Think of them as smart containers for data that know how to merge changes automatically, even when multiple people modify the same information at the same time.
The core idea behind CRDTs is elegantly simple: instead of trying to prevent conflicts, they're designed so conflicts are automatically resolved deterministically, ensuring eventual consistency. This is achieved through careful mathematical design that makes operations commutative (order doesn't matter), associative (grouping doesn't matter), and idempotent (applying the same operation multiple times has the same effect as applying it once).
CRDTs have become increasingly important as we've moved toward a world where users expect real-time collaboration in everything from commenting systems to document editors. They solve a fundamental problem in distributed computing: how do you keep data consistent across multiple locations without requiring a central authority to coordinate every change?
CRDTs guarantee that all replicas will eventually reach the same state, regardless of the order in which operations are received or applied.
How CRDTs Work
CRDTs operate on two fundamental approaches: state-based and operation-based synchronization. State-based CRDTs (also called CvRDTs) work by periodically sharing the entire state of the data structure between replicas. When a replica receives a state update, it uses a merge function to combine the received state with its own local state.
Operation-based CRDTs (CmRDTs) take a different approach. Instead of sharing states, they broadcast the actual operations that modify the data. Each replica applies these operations to its local copy, and the mathematical properties of the operations guarantee that all replicas reach the same final state.
The trade-offs between these approaches are important. State-based CRDTs are simpler to implement and more tolerant of message loss, since missing a state update just means you'll get the next one. However, they can use more bandwidth since they're sending complete states rather than just changes.
Types of CRDTs
CRDTs come in several fundamental types, each designed for specific use cases and data patterns. Understanding these types helps you choose the right approach for your collaborative application.
G-Counter (Grow-only Counter): The simplest CRDT, designed for values that only increase. Each replica maintains a vector of counters, one per replica, and the global value is the sum of all counters. Perfect for tracking likes, votes, or view counts where you never need to decrement.
PN-Counter (Positive-Negative Counter): Extends G-Counter to support both increments and decrements by maintaining separate grow-only counters for positive and negative operations. The final value is the difference between the two counters.
G-Set (Grow-only Set): A set where elements can only be added, never removed. Merging is simple: take the union of all sets. Useful for collecting tags, categories, or any scenario where removal isn't needed.
OR-Set (Observed-Remove Set): A more complex set that supports both additions and removals. Each element is tagged with unique identifiers, and removals are tracked separately. An element is in the final set only if it has been added but not removed.
Sequence CRDTs: The most complex type, designed for ordered data like text documents or lists. These include algorithms like WOOT, Logoot, and YATA. They assign unique identifiers to positions and use sophisticated algorithms to maintain order when concurrent insertions occur.
LWW-Register (Last-Writer-Wins Register): Stores a single value with a timestamp. When conflicts occur, the value with the latest timestamp wins. Simple but requires synchronized clocks and may lose data in true concurrent scenarios.
The choice between these types depends heavily on your specific use case. React commenting systems might use OR-Sets for managing comment threads and Sequence CRDTs for rich text content, while document collaboration typically relies heavily on Sequence CRDTs for text synchronization.
CRDT vs Operational Transformation
The debate between CRDTs and Operational Transformation (OT) shows two fundamentally different approaches to collaborative editing. OT, the older of the two technologies, was pioneered by systems like Google Docs and has been battle-tested in production for over a decade.
Operational Transformation works by changing operations based on the context in which they're applied. When two users make concurrent edits, OT algorithms change one operation based on the other to maintain consistency. This typically requires a central server to coordinate changes and maintain a canonical operation history.
CRDTs take a mathematically different approach. Instead of changing operations after the fact, they're designed so that operations naturally commute and don't require modification. This allows truly decentralized collaboration where any replica can accept operations without coordinating with a central server.
The trade-offs are major. OT generally provides better preservation of user intent, especially in rich text editing scenarios. When you type "hello" and someone else simultaneously deletes the word you're typing into, OT can make more intuitive decisions about what the final result should look like.
In practice, many Google Docs-style commenting systems use hybrid approaches, using the strengths of both technologies. The choice often comes down to your specific requirements around offline support, decentralization, and the complexity of operations you need to support.
CRDT Implementation Libraries
The CRDT ecosystem has matured, offering developers several strong options for implementing collaborative features. Each library takes a different approach and excels in different scenarios.
Yjs stands out as the most popular and mature CRDT library. It implements a sophisticated sequence CRDT optimized for text editing and supports rich data types including text, arrays, maps, and XML. Yjs provides excellent performance and has bindings for multiple editors including Monaco, CodeMirror, and Quill. Its network-agnostic design means you can use it with WebSockets, WebRTC, or any other transport layer.
Automerge takes a different approach, focusing on JSON-like data structures with a clean API. It's designed to feel like working with regular JavaScript objects while providing automatic conflict resolution. Automerge recently released a Rust-based implementation that greatly improves performance, making it viable for larger documents.
ShareJS, while not a CRDT library, is an important older library built on the alternative technology, Operational Transformation (OT). It's powerful for text-focused collaboration but relies on a central server to resolve conflicts. The project is less actively maintained than modern CRDT alternatives and is generally included for historical context.
Diamond Types shows the cutting edge of CRDT library research, implementing novel algorithms that promise better performance and smaller memory footprints. While still experimental, it shows the direction the field is heading.
For developers building notification systems or coding tools, the choice of library often depends on your specific requirements:
Choose Yjs if you need proven stability and extensive editor support
Choose Automerge if you prefer working with JSON-like data structures
Choose ShareJS if you're building primarily text-focused applications
Consider newer libraries if you have specific performance requirements or novel use cases
Building Realtime Collaborative Applications with Velt
While CRDTs provide a solid theoretical foundation for collaborative applications, implementing them correctly requires deep expertise and ongoing maintenance. Most development teams face a choice: spend months building and debugging CRDT infrastructure, or focus on their core product features.
Velt tackles this challenge by providing a complete collaboration layer that uses CRDT principles alongside other proven technologies. Instead of implementing sequence CRDTs for text synchronization or building presence management from scratch, you can integrate battle-tested components that handle the complexity for you.
The practical benefits extend beyond just saving development time. Velt's approach includes features that go well beyond basic CRDT functionality: contextual comments that attach to specific DOM elements, live video huddles for synchronous collaboration, and recording features with AI transcription. These features require sophisticated coordination between multiple collaborative technologies.
Consider the complexity involved in building a commenting system that supports real-time updates, threaded conversations, mentions, and reactions. You'd need CRDTs for conflict-free text editing, Operational Transformation algorithms for rich text formatting, presence management for showing active users, and notification systems for keeping users informed.
Velt's component-based architecture lets you add these features with just a few lines of code:
Live State Sync: CRDT-backed synchronization of application state and user selections
Contextual Comments: Figma-style comments that attach to any part of your interface
Real-time Presence: Show who's online and where they're working
Video Huddles: One-click audio/video calls without leaving your application
Recording & Playback: Loom-style recording with AI-powered transcriptions and summaries
The customization options go far beyond simple theming. You can modify behavior, add custom data fields, implement conditional display logic, and integrate with your existing authentication and authorization systems. This flexibility means you're not locked into a rigid collaboration model.
For applications in specialized domains like form builders, the combination of CRDT-based synchronization with domain-specific collaboration features creates experiences that would be extremely difficult to build from scratch.
FAQ
What is the main difference between CRDTs and OT?
CRDTs are designed so conflicts cannot occur mathematically, allowing decentralized collaboration without a central server, while Operational Transformation (OT) modifies operations through a central coordinator but generally preserves user intent better in complex editing scenarios.
How do I choose the right CRDT type for my application?
Use G-Counter for simple metrics like view counts, OR-Set for collaborative lists where items can be added/removed, Sequence CRDTs for text editing, and PN-Counter for values that need both increment and decrement operations like shopping cart quantities.
When should I use a CRDT library versus building my own implementation?
Use proven libraries like Yjs or Automerge unless you have very specific requirements. Implementing CRDTs correctly requires deep mathematical understanding and extensive testing, while mature libraries provide tested performance and editor integrations.
Can CRDTs work offline and sync when connectivity returns?
Yes, CRDTs are designed for offline-first applications: users can make changes locally while disconnected, and all changes will automatically merge conflict-free when connectivity is restored.
Final thoughts on conflict-free replicated data types
CRDTs solve one of the hardest problems in collaborative software: keeping everyone's changes in sync without breaking things. While the math behind them is complex, you don't need to become a CRDT expert to build great collaborative features. A solid realtime SDK like Velt handles the tricky parts while you focus on what makes your app unique.
