Sync Strategy Tradeoffs
Choose sync by product semantics and operational budget.
| Strategy | Best fit | Tradeoff |
|---|---|---|
| Backup-only | privacy-first single-user apps | no live cross-device state |
| Manual export/import | user-owned files and low-frequency moves | merge UX is manual |
| Server-authoritative mutation replay | offline writes with account-backed state | needs idempotency, rebase, and server validation |
| Subset sync | local clients need a filtered server data set | shape authorization and schema evolution matter |
| CRDT sync | collaborative multi-writer editing | hard data modeling, tombstones, compaction, debugging |
Recommendation
For a solo-dev app:
- Start with backup-only.
- Add manual import/export if users need portability.
- Add mutation replay if users need offline writes against server state.
- Add subset sync if the server has large data but clients need only slices.
- Add CRDTs only for true collaboration.
Operational Checklist
Real sync needs:
- durable local queue
- idempotency keys
- server-side mutation log or version checks
- conflict handling rules
- retry and backoff
- auth refresh path
- observability for stuck queues
- migration policy for mixed client versions
Gotcha: A cloud database SDK that caches locally is not automatically a sync strategy. You still need conflict, retry, migration, and recovery semantics.