Local-First Data and Offline Sync

Local-first data means the app remains useful when the network is slow, absent, expensive, or intentionally unused. Start by making the local data durable, exportable, restorable, and testable. Add multi-device sync only when the product actually needs it.

The default ladder for small apps is simple:

  1. Store source-of-truth data locally.
  2. Add safe migrations before shipping schema changes.
  3. Add export/import and restore drills before sync.
  4. Add encrypted backup if the data is private.
  5. Add sync when backup-only no longer solves the user problem.

Gotcha: Offline-first is not the same as sync-first. A local-only app with good export and backup is often more trustworthy than a half-built sync engine.

Decision Ladder

NeedStart withAdd later
Android relational app dataRoom over SQLiteWorkManager backup/sync jobs, encrypted backup
Web structured offline dataIndexedDB, usually through Dexiepersistent storage request, worker-backed exports, sync queue
Desktop app stateSQLite in app data directoryapp-document exports, OS keychain/Stronghold, backup rotation
Human-editable knowledgeMarkdown, JSON, JSONL, attachmentsSQLite/FTS index as derived data
Privacy-first finance/health datalocal DB, lock screen, CSV/JSON exportuser-owned encrypted backup, optional account sync
Collaborationserver-authoritative mutations or CRDTsconflict UI, audit log, observability

Read First

Contents

Architecture

Concepts

Quickstarts

How-To Guides

Deep Dives

Walkthroughs

Troubleshooting

Notes

Opinionated Take

For a solo-dev app, ship local durability before sync. For privacy-sensitive apps, ship export and encrypted backup before accounts. For collaboration-heavy apps, choose a sync architecture early because conflict semantics shape the data model.

Do not make CRDTs the default answer. Use them when multi-writer collaboration is core to the product and when you can test, explain, and debug merges.