Mobile database offline sync: keeping field apps working without a connection

Many apps are built as screens over a web service. On a desk that works. In the field it breaks in familiar ways: a form is lost when the connection drops, a worker waits at a spinner, or a team copies data to paper and types it in later.

Teams usually choose between three options:

• Retry on failure. The app queues a failed request and sends it later. This is simple and covers short drops, but the app still cannot read data it does not already hold.
• Cache some screens. Selected data is stored on the device. This helps reading, but writing and merging changes become your own code to write and test.
• A local database with built-in sync. The device holds a real database and a sync service reconciles it with the server. This is the model Couchbase Mobile is built for.

The third option costs more to design, but it removes the part teams usually get wrong, which is merging changes made at different times in different places.

In Couchbase Lite, a replicator moves changes between the device and Sync Gateway. Couchbase's documentation describes the behaviour that matters offline:

• Continuous or one-shot. A continuous replication stays active to replicate changed documents; a one-shot run is the ad-hoc alternative.
• Offline and retry. On a temporary error the replicator goes into an offline state and retries, with the interval between attempts growing over time. Continuous replications retry without limit.
• Channels. By default the device pulls the channels its user may access. You can limit a pull to chosen channels, so a device holds only the data it needs.
• Access control. Sync Gateway checks that only authorised users connect, and which documents each user may read and write.

Channel design matters more than it looks. It decides how much data lands on each phone, and so storage use, sync time and what is exposed if a device is lost.

Conflicts are not rare in offline apps. Two technicians open the same job, both edit it with no signal, and both sync later. Couchbase Lite handles this during pull replication. By default, a deleted document wins over an update, and if both are updates, the revision with the most revisions wins. From Couchbase Lite 2.6, a custom resolver can pick the winner with your own logic, and built-in strategies include Local Wins, Remote Wins and Merge.

The default may be wrong for your business. A work order edited in two places may need both sets of notes kept. Decide the rule per record type with the business owners, and test it with real devices going offline, before the first release.

Couchbase is an Interkey technology partner, and the platform is Couchbase's. Interkey sells Couchbase Capella, and as of 2 November 2026 Couchbase's region list shows App Services available in Google Cloud's Dammam region (me-central2), as set out on our Capella page. Check Couchbase's current list before you decide.

We start with a workload review: the access patterns, how often devices are offline, volumes, and any rule on where data must stay. That is enough to say whether the model fits and whether Capella or self-managed Couchbase Server suits it. Some apps need none of this, and a simple retry queue is the honest answer.