Offline-first sync to devices

Keeping a copy of the data on each phone, browser or laptop, letting people read and write it with no connection, and merging the changes when they reconnect.

Document databases Cross-platform mobile apps

What it asks of a system

An offline-first app treats the copy on the device as the one it works with. Reads and writes go to a local database straight away, and a sync layer sends local changes to a server and pulls in everyone else’s when there is a network. The hard part is two devices changing the same record while apart. Systems answer that in different ways: Firestore’s offline cache lets the last write win; CouchDB keeps every conflicting revision, shows the same winner on every replica and leaves the losers for the application to merge; CRDT-based libraries merge most concurrent edits automatically.

When you compare systems, check what runs on the device (a full database, or a cache of recent queries), whether it syncs only the subset a user may see, how conflicts are detected and resolved, how long a device can stay offline, and whether the server side can be self-hosted or is tied to one cloud.

Good at it · 2

Compare side by side

Relational databases

TursoOpen sourceTurso Sync gives an app a local database that takes writes first and exchanges them with Turso Cloud through `push()` and `pull()`.A from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.

Document databases

Apache CouchDBOpen sourceAny copy can take writes and sync both ways over the Couch Replication Protocol, which PouchDB speaks in browsers and phones.A JSON document database spoken to entirely over HTTP, built around replication: any two copies can sync in either direction and keep conflicting edits instead of losing them.

Sources

Why each technology is listed comes from the sources on its own page.