---
title: "CRDTs for Mobile Sync: Automerge vs Yjs vs cr-sqlite"
published: true
description: "Compare Automerge, Yjs, and cr-sqlite for offline-first mobile sync. Benchmarks, merge semantics, and architecture patterns that eliminate conflict dialogs."
tags: mobile, architecture, kotlin, performance
canonical_url: https://blog.mvpfactory.co/crdts-for-mobile-sync-automerge-vs-yjs-vs-cr-sqlite
---
## What We're Building
Today we're walking through a practical comparison of three CRDT libraries — Automerge, Yjs, and cr-sqlite — so you can pick the right one for offline-first mobile sync. By the end, you'll understand how each one handles concurrent edits, what their sync payloads actually look like on the wire, and how they perform on real mobile hardware. No more conflict resolution dialogs. No more "which version do you want to keep?"
## Prerequisites
- Familiarity with offline-first architecture concepts
- Basic understanding of SQLite and document-based data models
- A Kotlin, Swift, or TypeScript project where you want to add local-first sync
## Step 1: Understand Why CRDTs Eliminate Conflict Dialogs
CRDTs (Conflict-free Replicated Data Types) guarantee that any two replicas receiving the same set of operations converge to the same state, regardless of operation order. Two families matter: state-based (CvRDTs) that ship full snapshots, and operation-based (CmRDTs) that ship individual ops. Modern libraries like Automerge and Yjs use hybrid approaches — encoding operations into compact binary formats and reconstructing state locally.
Here is the minimal setup to get this working: you need a way to order edits causally across devices. All three libraries rely on Hybrid Logical Clocks.
kotlin
data class HLC(
val wallTime: Long, // millis since epoch
val counter: Int, // logical ticks
val nodeId: String // unique device identifier
) : Comparable {
override fun compareTo(other: HLC): Int =
compareValuesBy(this, other, { it.wallTime }, { it.counter }, { it.nodeId })
}
When two devices edit the same field concurrently, the HLC timestamps are incomparable. The CRDT's merge function kicks in with a deterministic tiebreaker (like highest `nodeId` wins). Users never see a dialog because the merge is automatic and identical across all replicas.
## Step 2: Compare the Three Libraries
Let me show you a pattern I use in every project — matching the library to the data shape.
| Dimension | Automerge 2.x | Yjs | cr-sqlite |
|---|---|---|---|
| Data model | Rich JSON documents (maps, lists, text) | Shared types (YMap, YArray, YText) | SQLite tables with CRDT columns |
| Merge granularity | Per-character / per-field | Per-character / per-field | Per-row / per-column |
| Language support | Rust core, WASM, JS, Swift, Kotlin (via FFI) | JS-native, Rust port (y-crdt) | C core, bindings for most platforms |
| Best fit | Collaborative documents, nested structures | Real-time text, lightweight state | Apps already on SQLite, relational data |
Automerge has the richest document model. Yjs has the lowest memory footprint. cr-sqlite fits teams already invested in SQLite.
## Step 3: Measure What Matters on Mobile
The docs don't mention this, but most teams benchmark CRDT size at rest and ignore sync cost. The sync architecture matters more than you'd think.
- **Yjs** uses a state vector (`{clientId: clock}` pairs). Typical sync payload for a 10KB document with 50 pending ops: ~2–4 KB.
- **Automerge** uses Bloom filters to identify missing changes. Slightly higher overhead per round-trip but fewer rounds for large change sets.
- **cr-sqlite** piggybacks on SQLite's replication patterns, shipping row-level diffs via a per-row version clock.
Here is the gotcha that will save you hours — memory on device:
| Scenario (10K ops) | Automerge 2.x | Yjs | cr-sqlite |
|---|---|---|---|
| Heap memory | ~8–12 MB | ~3–5 MB | ~2–4 MB |
| Load time (cold) | ~120–200 ms | ~40–80 ms | ~20–50 ms |
| GC pressure | Medium | Low | Minimal |
cr-sqlite wins on memory because SQLite manages its own page cache outside the Kotlin/JS heap. For Android Go phones with 2 GB RAM, cr-sqlite or Yjs are safer choices. Automerge is the better pick when your data model is deeply nested and document-shaped.
## Gotchas
- **Operation history grows unbounded.** CRDTs trade storage for conflict freedom. Without compaction, memory on low-end devices degrades over weeks. Use Automerge's `clone()` to strip history, Yjs's `encodeStateAsUpdate` for snapshots, or cr-sqlite's version pruning.
- **Don't force relational data into a document CRDT** (or vice versa). Foreign keys and joins point to cr-sqlite. Nested maps and lists point to Automerge. Lightweight collaborative state points to Yjs.
- **Prototype your sync loop first.** Stand up a minimal WebSocket relay, simulate 48 hours of offline edits on two devices, and measure actual payload sizes on your real data model. The benchmarks above are directional — your mileage depends on edit patterns.
- **Automerge FFI overhead on native mobile adds latency.** The Rust/WASM core avoids GC on web, but crossing the FFI boundary on Android or iOS has measurable cost on cold loads.
## Wrapping Up
Local-first has matured. With CRDT libraries available across Kotlin, Swift, and TypeScript, the engineering cost of eliminating conflict dialogs has dropped below the cost of building a custom server-authoritative sync layer. Match the library to your data shape, budget for history compaction, and prototype before you commit. I'd make the switch on any new project that handles user-generated content offline.
Top comments (0)