Two places a change can travel
Every sync system answers the same question: when a change is made on one device, how does it reach the others?
Cloud sync sends it to a server. The server stores the change and passes it on to every other device that needs it, the next time each one connects. Cloud Firestore works this way: its offline persistence keeps a local copy of the data the app is using, lets the app read and write it while offline, and synchronizes local changes with the Cloud Firestore backend when the device comes back online. Apple’s Core Data can mirror a local store to CloudKit in the same spirit.
Peer-to-peer sync sends it straight to other devices. When two phones are near each other, they find each other over Bluetooth or a shared local network and exchange the changes each is missing. No server takes part. Ditto’s documentation, for example, describes devices that sync with each other through a peer-to-peer mesh and choose which data they want with subscription queries.
The two are not exclusive. A device can sync with nearby peers now and with a server later, as long as the data model can merge changes that arrive by different routes.
What each one is good at
| Cloud sync | Peer-to-peer sync | |
|---|---|---|
| Devices far apart | Works whenever both have internet | Needs a path through other devices or a relay |
| Devices in the same room, no internet | Waits for a connection | Syncs directly |
| A single authoritative copy | The server holds it | No copy is authoritative by default |
| Access control | Enforced in one place, the server | Enforced on every device, with keys |
| Backups and history | On the server | On the devices, unless one also syncs to a server |
| Running cost | Server, storage, and bandwidth | No server in the local path |
The table shows why the choice usually follows the setting. An office team with good connectivity gets little from peer-to-peer sync. A crew on a ship, a team at a remote site, or staff in a packed venue get the most from it, because they are together exactly when the internet is not.
The data model is what makes it work
Sync through a server can rely on the server to order changes and settle conflicts. Peer-to-peer sync cannot: two devices may edit the same record while apart and meet again later, with no referee. That is why peer-to-peer sync usually rests on data types designed to merge without coordination, such as CRDTs. Yjs, a CRDT library, states that it makes no assumptions about the network: as long as all changes eventually arrive, the documents sync, in whatever order the updates are applied.
The local-first research from Ink & Switch puts this as one of seven ideals, “the network is optional”: software should keep working, and keep syncing where it can, without depending on a server being reachable. It argues that the primary copy of the data should live on the user’s devices, with servers in a supporting role.
How sync conflicts are resolved covers the merge rules in more detail.
Trade-offs to plan for
Peer-to-peer sync moves some responsibilities from the server onto every device:
- Authorization. Without a central server to check every write, devices need to know which peers may read and change which data. Encryption keys and signed identities take the server’s place.
- Discovery and transport. Devices have to find each other and keep a link up, which depends on radios, permissions, and background limits on phones.
- Storage. Each device keeps the history it needs to merge, so document size and retention matter more.
- Business rules. Merging guarantees that copies converge, not that the result is valid. A rule such as “a slot can only be booked once” still needs an authority, which is often the backend once it is reachable.
Cloud sync keeps those in one place but stops at the edge of coverage.
Using both
A common pattern is to treat the backend as the system of record and use peer-to-peer sync for the time between connections. Devices exchange changes locally while they are together and offline. When any device reaches the internet, it sends the accumulated changes to the backend, which applies its business rules and becomes the reference again. Because the merges are deterministic, the order in which changes arrive does not change the result.
Offline Protocol’s replicated documents follow this pattern. Devices in an encrypted space edit documents offline and merge them when they meet, while the application’s own database stays the system of record for everything outside that shared scope.