Where the copy that counts lives
Every app that syncs keeps data in more than one place. The real difference between cloud-first and local-first is which copy wins.
The Ink & Switch essay that coined local-first software describes cloud apps this way: the data on the server is the primary, authoritative copy, and a client’s copy is merely a cache that is subordinate to the server. Any change has to be sent to the server, or it did not happen. Local-first swaps those roles. The copy on the person’s laptop, tablet or phone is primary, and servers still exist but hold secondary copies to help with access from several devices.
That one decision shapes almost everything else about the app.
How the two compare
| Cloud-first | Local-first | |
|---|---|---|
| Reading and writing | A change needs a round trip to the server to count | Reads and writes go to local storage; sync runs in the background |
| No connection | The app queues work or stops, depending on its offline support | The app keeps working with its full data |
| Collaboration | The server orders changes and settles conflicts | Copies merge, for example with CRDTs |
| Access control | Enforced in one place, the server | Enforced by keys and membership on every device |
| Business rules | The server is a natural authority | Rules needing one authority still need one |
| If the service shuts down | The app and its data can go with it | The data stays on the devices |
The essay notes that with cloud apps all data modifications, and many lookups, need a round trip to a server, so network distance limits how fast the software can feel. Optimistic interfaces hide some of that delay but still expose it when a request fails. A local-first app reads and writes the local disk and never waits on a server to finish a request.
Longevity is the other large difference. The essay points out that if a cloud service shuts down, the software stops working and the data created with it can be lost, and cites Parse, a backend service that Facebook acquired and then shut down in 2017, forcing the apps built on it to move.
The middle ground: offline-capable cloud apps
Some apps sit between the two. A cloud database with an offline cache lets an app keep working without a connection while the server stays in charge. Cloud Firestore’s offline persistence caches the data the app is actively using, lets the app read, write and query it offline, and synchronises local changes with the backend when the device comes back online. For several changes to the same document, the last write wins. On Android and Apple platforms this persistence is on by default; on the web it is off by default.
Some sync engines make the server’s authority explicit. PowerSync describes its design as server-authoritative: if the backend does not apply a write the client uploaded, the next checkpoint from the server will not contain it, and the change is removed from the client.
Both are offline-first designs, not local-first ones, because the server’s copy decides. Offline-first vs local-first covers that distinction in depth.
What local-first asks of you
Putting the primary copy on the device moves work from the server to every client:
- Merging. Devices edit apart and meet later with no referee. Libraries such as Automerge use CRDTs so that concurrent changes on different devices merge automatically without a central server.
- Access control. The essay observes that permissions built for centralised systems do not apply directly, since anyone holding a copy can modify it locally; other users can only choose whether to accept those changes.
- Schema changes. With no central database there is no single place to run a migration. How schema migrations work in a local-first app explains the patterns.
- Storage and deletion. Each device keeps what it needs to merge, and deleting data means reaching every copy.
The essay’s authors were candid about maturity: writing in 2019, they said the technologies were good for prototypes but that it was not yet advisable to replace a proven product like Firebase with an experimental project like Automerge in production. Check the current state of any library before relying on it.
Choosing between them
The choice is rarely all or nothing, and it is best made per kind of data.
- Cloud-first fits data that needs one authority at all times: payments, stock levels, bookings, anything where two offline edits could both be valid alone and wrong together.
- Local-first fits data people create and own: notes, drawings, checklists, field records, documents edited together, and anything that has to work where the network does not reach.
- Both together is a workable pattern: local-first documents for the work people do in the field, and a backend that remains the system of record for the rest. Can local-first apps still have a backend? looks at what that backend can do. The route changes take between devices is a separate choice, covered in peer-to-peer sync vs cloud sync.