Offline-first and sync

How much does it cost to add offline sync to an app?

The cost of offline sync has three parts. There is the engineering to store data on the device, queue changes, and resolve conflicts. There is the running cost of whatever service syncs the data, which cloud databases usually bill by operations, storage, and bandwidth. And there is the testing needed to trust it. Peer-to-peer sync between nearby devices changes the second part, because data that moves device to device does not pass through a metered server.

Learning objectives

After reading this article you will be able to:

  • Identify the build, running and testing costs of adding offline sync
  • Explain how a cloud database with an offline cache bills for sync
  • Describe what peer-to-peer sync removes from the running cost

The three parts of the bill

“How much does sync cost?” usually gets answered with a price list, but the price list is only one of three costs.

  1. Building it into the app. A local store, a way to record changes made offline, logic to send them when a connection returns, conflict handling, and interface states that tell people what has and has not synced.
  2. Running it. Whatever moves data between copies: a cloud database, a sync service, your own server, or nothing at all when devices sync directly.
  3. Trusting it. Testing every way a device can lose and regain a connection, and the edge cases that only show up in the field.

The second part is the one with a published rate. The first and third have none; they depend on your app.

Building it into the app

Android’s offline-first guidance describes the usual shape. A local data source is the source of truth the interface reads from. Writes go to it first and are sent to the network later, either straight away when possible or through a queue that drains when the device reconnects. When the same data changed in two places, the app needs a conflict-resolution strategy; the guide describes a common one, last write wins, in which the network keeps the newest write and discards older data.

Every one of those pieces is work: the local schema and its migrations, the change queue, retries, conflict rules per field, and the interface for pending, failed, and synced states. A sync library or service removes some of it, not all. Your conflict rules and your interface remain yours, because they depend on what the data means.

Running it

How the running cost is measured depends on where the data goes.

A cloud database with an offline cache. Cloud Firestore is an example. Its offline persistence keeps a local copy of the data the app is using, lets the app read and write it offline, and synchronizes local changes when the device is back online, with last write wins for several changes to the same document. Its pricing page says you are charged for documents read, written, and deleted, index entries read, storage, and network bandwidth, with a free quota to start. Under a model like this, the cost grows with how much data changes and how many devices read it.

A sync service or your own server. Sync vendors publish their own pricing models, and running your own server swaps a bill for hosting and operations time. Read each vendor’s pricing page for the unit it charges by.

Peer-to-peer sync. When nearby devices exchange changes directly, over Bluetooth or a local network, no server sits in the path, so there is nothing to meter for that traffic. The local-first research from Ink & Switch treats this as a goal in its own right: data that lives on the user’s devices and syncs between them, with servers as optional helpers. An app can still keep a backend as the system of record and use peer-to-peer sync for the moments when it cannot be reached.

Trusting it

Sync code fails in ways that only appear under specific sequences: an edit made offline on two devices, a write that half-reached the server, a device that comes back after a week. Budget for:

  • tests that cut the connection at each step of a write
  • two devices editing the same record while apart, then reconnecting
  • restarts and app updates while changes are still queued
  • long disconnections, near the limits of any queue or retention window

This cost does not show up on an invoice.

How Offline Protocol is priced for sync

Offline Protocol’s replicated documents sync between devices that share an encrypted space, directly or across the mesh, and merge by a fixed rule per collection type. The cost parts break down like this, from the live pricing page:

  • The SDK. The mesh SDK is free under AGPL-3.0-only, including in production, when the app meets the AGPL obligations. Closed-source apps, Apple App Store apps, and closed-source firmware need the commercial license, which is annual and has no published price.
  • Local sync. Traffic that moves device to device over a local transport is never metered, on any plan.
  • Hosted services, if you use them. Messages that go through the hosted relay when no local path exists are metered per delivery: 10,000 a month on Free, 100,000 on Pro ($99 a month), and 1 million on Scale ($499 a month), then $0.50 per 1,000. Devices using the hosted relay sign in with OfflineID, which is counted by monthly active users.
  • Your backend. Replicated documents do not replace your backend’s database, so its cost stays as it is.

The engineering and testing parts still apply: the docs ask you to verify edits with the backend disconnected and again after a peer partition before relying on sync.

Frequently asked questions

Is there a free way to add offline sync?

Some options cost nothing to run for small apps, such as a cloud database's free quota or a peer-to-peer library under an open-source license. The engineering and testing cost remains, and a copyleft license or a quota can change the answer as the app grows.

Does Offline Protocol charge for syncing documents?

Not when devices sync directly. Local peer-to-peer traffic is never metered on any plan. Messages that go through the hosted relay when no local path exists are metered per delivery, with 10,000 a month included on the Free plan.

Sources

Build it with Offline Protocol

The shared state guide shows replicated documents that devices edit offline and merge when they meet, with the merge rule for each collection type and the two interruptions to test before relying on it.

Read the shared state guide