Firebase offline persistence features and limits
Cloud Firestore’s offline persistence caches a copy of the data the app is actively using. While the device is offline the app can write, read, listen to and query that cached data, and listeners fire when the cached data changes. When the device comes back online, Firestore synchronizes the app’s local changes with the Firestore backend. For several changes to the same document, Firebase’s documentation says the last write wins.
As of October 2026, the documentation sets these limits and defaults:
- Offline persistence is supported only in Android, Apple and web apps. It is on by default on Android and Apple platforms and off by default on the web.
- The cache covers documents the app has received. A query for a collection with nothing cached returns an empty result, and fetching a single uncached document returns an error.
- The default cache size threshold on Android and Apple platforms is 100 MB, after which Firestore cleans up older, unused documents.
- Transactions fail when the client is offline. Batched writes still execute.
Firebase’s Realtime Database has a similar model: with disk persistence enabled, cached data stays available and queued writes are sent when the connection returns. Its documentation notes that transactions made offline are queued but not persisted across app restarts.
Offline Protocol device-to-device sync
Offline Protocol is a mesh SDK inside the app on each device. Devices discover each other over Bluetooth LE and exchange messages and replicated documents inside MLS-encrypted sessions or groups. Each device edits its own copy of a document and the copies merge by fixed rules when the devices reconnect: last writer wins per map key, concurrent list insertions are kept, text merges by character, and counters add up. In version 0.30.0 the React Native package runs in native iOS and Android builds, including Expo development builds, but not in Expo Go or a browser.
It holds no hosted copy of your data. Your backend, which can be Firestore, stays the system of record.
Firebase offline persistence vs Offline Protocol
The main difference is where the primary copy lives and the path a change takes: Firestore keeps it on the backend and sends every change through it, while Offline Protocol keeps it on the devices and lets them exchange changes directly.
| Firebase offline persistence | Offline Protocol | |
|---|---|---|
| Where the primary copy lives | On the Firestore backend; the device holds a cache | On the devices; the app sends records to its backend when it chooses |
| Path of a change | Device to the Firestore backend, then to other devices’ caches | Device to a nearby device over Bluetooth LE, or through a hosted relay when no local path exists |
| Two phones side by side, no internet | Each works from its own cache; neither sees the other’s changes | They exchange changes directly |
| Conflicts | Last write wins per document | Fixed merge rule per collection type |
| Queries | Firestore queries, including on cached data | None; documents are read as JSON |
| Access control | Firebase Security Rules on the backend | Membership of an encrypted space; the app decides who may join |
| Platforms (as of October 2026) | Offline persistence on Android, Apple and web apps | React Native on iOS and Android; Rust; Python on PyPI; Java on Maven Central; a C API through offline_protocol.h in the desktop archives; early native Swift and Android packages; a preview Flutter plugin, not on pub.dev yet |
Firebase and Offline Protocol running costs
As of October 2026, Firebase has a no-cost Spark plan and a pay-as-you-go Blaze plan. Cloud Firestore’s Standard edition includes 1 GiB of stored data, 50,000 document reads, 20,000 writes and 20,000 deletes a day, and 10 GiB of outbound data a month at no cost; usage beyond that is billed at Google Cloud rates on Blaze. Firestore’s pricing page also notes that with offline persistence enabled, a listener that has been disconnected for more than 30 minutes is charged on reconnection as if it had issued a brand-new query.
Under this model every edit a crew member makes counts as a document write, and every colleague who needs to see it reads it from the backend, even when the two of them are standing in the same room. With Offline Protocol, traffic between devices over a local transport is never metered on any plan. The mesh SDK is free under AGPL-3.0-only when the app meets its obligations, and closed-source or App Store apps need the commercial license, which is annual with no published price. The optional hosted services (sign-in, the hosted relay, telemetry) run on plans from $0, with Pro at $99 a month and Scale at $499 a month.
Best fit for Firebase
Firestore is the better fit for most apps whose users are usually online and want a managed backend database, and its offline cache needs no extra code. Choose it if:
- You want a managed backend database with queries, security rules and authentication, and your users are usually online.
- Offline means short gaps for each user on their own, such as a lost signal on a train, rather than a group working together without a connection.
- You also need the web, where Offline Protocol’s mesh SDK does not run.
Best fit for Offline Protocol
Offline Protocol fits when nearby devices must exchange changes directly while the backend is unreachable. Choose it if:
- People working near each other must see each other’s changes while the backend is unreachable, such as a crew below deck on a ship or underground in a mine.
- Handoffs and shared checklists between nearby devices should not each count as a backend write plus a read for every colleague.
- Messages and shared state between devices need to be end-to-end encrypted with MLS.
Using Firebase with Offline Protocol
A common split keeps Firestore as the system of record and uses Offline Protocol for the time devices spend together without it. Devices exchange changes locally. When a device has the agreed result, the app writes it to Firestore; if the device is still offline, Firestore queues the write in its cache and synchronizes it when the connection returns. Decide which device writes each record to the backend, or make the write idempotent, so that several devices holding the same merged state do not each submit it.