Offline-first and sync

Offline Protocol vs PowerSync

PowerSync keeps a SQLite database on each client in sync with a backend database such as Postgres or MongoDB, through the PowerSync Service, and sends local writes back through your own backend. Offline Protocol is an SDK that lets nearby devices exchange messages and merge shared documents with each other directly, over Bluetooth LE, with no server in the path. PowerSync is the tool for getting each device its slice of your database; Offline Protocol is the tool for devices working side by side to stay in step with each other. An app can use both.

TL;DR

Use PowerSync when each device needs its own SQL-queryable slice of your backend database and changes can wait to travel through your backend. Use Offline Protocol when nearby people or machines must hand off work or edit shared state directly while the backend is out of reach. An app can run both, keeping each record on a single path.

Learning objectives

After reading this article you will be able to:

  • Describe the path a change takes in PowerSync and in Offline Protocol
  • Compare the two on conflict handling, queries, licensing and what each one bills for
  • Decide when to use PowerSync, Offline Protocol, or both in one app

PowerSync and Offline Protocol features

PowerSync syncs your backend database into SQLite on each device, and is made up of the PowerSync Service and a set of client SDKs. According to its documentation, the service replicates data from your backend database, partitions it by what each user should receive, and streams updates to a SQLite database inside each client. As of October 2026, the supported source databases are Postgres and MongoDB, with MySQL and SQL Server in beta, Azure DocumentDB in alpha and Convex marked experimental. Client SDKs cover JavaScript on the web, React Native and Expo, Node.js, Flutter, Kotlin and Swift, with Capacitor, .NET and Rust in beta.

Writes in PowerSync are applied straight to the local SQLite database and recorded in an upload queue. While the device is connected, the SDK calls an uploadData() function you write, which sends the queued changes to your own backend. Your backend keeps control of authorization, validation and business logic, applies what it accepts to the source database, and the result syncs back to every client.

Offline Protocol is a mesh SDK that runs inside the app on each participating device. In version 0.30.0 it is a React Native native module for iOS and Android, with a Rust core on crates.io, a Python package on PyPI, a Java package on Maven Central, a C API, early native Swift and Android packages and a preview Flutter plugin. Devices find each other over Bluetooth LE, open MLS-encrypted sessions, and exchange messages, replicated documents and service calls. A document holds maps, lists, text and counters; devices edit their own copies offline and merge deterministically when they reconnect. Messages can be relayed across several devices (an initial limit of 8 hops in version 0.30.0), and a hosted relay carries traffic when no local path exists.

Offline Protocol is not a database. Its documentation is explicit that the document store does not replace your backend’s query engine or business rules, and that your system of record stays authoritative for the records it owns.

PowerSync and Offline Protocol similarities

PowerSync and Offline Protocol both keep an app usable when the server cannot be reached. A PowerSync app reads and writes its local SQLite database and drains the upload queue later. An Offline Protocol app keeps its documents and queued messages on the device and exchanges them when a peer is in range.

Both also leave your backend in charge. PowerSync routes every write through your backend before it becomes shared state. Offline Protocol leaves the backend out of the local exchange, and the app submits the records the backend owns once it can reach it.

PowerSync vs Offline Protocol differences

The main difference is the path a change takes: in PowerSync it goes from the device through your backend and the PowerSync Service to the other devices, while in Offline Protocol it goes from a device to a nearby device.

PowerSyncOffline Protocol
What movesRows from your backend database into SQLite on each client, and queued writes back to your backendMessages and replicated documents between devices
Path of a changeDevice, your backend, the PowerSync Service, then the other devicesDevice to a nearby device over Bluetooth LE, relayed by other devices or a hosted relay when needed
Two devices side by side, backend unreachableEach keeps working locally; neither sees the other’s changes until both sync with the backendThey exchange changes directly
ConflictsYour backend decides; a straightforward implementation gives per-field last write winsFixed merge rule per collection: last writer wins per map key, concurrent list insertions kept, character-level text merge, counters add up
Queries on the deviceSQL over the local SQLite databaseNone; documents are read as JSON
Licensing (as of October 2026)Client SDKs Apache-2.0; the service is source-available under the Functional Source License for self-hosting, or provided under a commercial agreement in PowerSync CloudMesh SDK AGPL-3.0-only, or a commercial license
What is billed (as of October 2026)PowerSync Cloud plans count data synced, data hosted and peak concurrent clientsOnly hosted services; traffic between devices over a local transport is never metered

PowerSync and Offline Protocol running costs

As of October 2026, PowerSync Cloud has a Free plan (2 GB synced and 500 MB hosted a month, up to 50 peak concurrent clients, deactivated after a week of inactivity), Pro from $49 a month (30 GB synced, 10 GB hosted and 1,000 peak concurrent clients included, then $1 per GB synced, $1 per GB hosted and $30 per 1,000 clients), Team from $599 a month, and custom Enterprise pricing. The self-hosted Open Edition is free. Under this model the bill follows how much data moves through the service and how many devices are connected at once.

Offline Protocol’s mesh SDK is free under AGPL-3.0-only, including in production, when the app meets the AGPL obligations. Closed-source apps and apps distributed through the Apple App Store need the commercial license, which is annual and has no published price. Hosted services are optional and run on Free ($0), Pro ($99 a month) and Scale ($499 a month) plans. The day-to-day saving comes from work that stays local: a checklist two technicians edit in the same plant room, or a job a driver hands to a yard operator, moves device to device without a round trip to a server and without a metered unit.

Best fit for PowerSync

PowerSync is the better choice when each device needs its own slice of your backend database, because Offline Protocol does not sync a backend database to devices. Choose it if:

  • Your data lives in Postgres, MongoDB, MySQL or SQL Server, and each device needs its own slice of it offline, queryable with SQL.
  • Devices reach your backend often enough that changes can wait to travel through it.
  • You ship on the web, Flutter, Kotlin or Swift as well as React Native. PowerSync publishes SDKs for each of these, while Offline Protocol’s Flutter plugin is a preview that is not on pub.dev yet and its native Swift and Android packages are early.

Best fit for Offline Protocol

Offline Protocol is the tool for devices working side by side to stay in step with each other. Choose it if:

  • People or machines working near each other need to hand off work or edit the same state directly, including when the backend is out of reach for a shift.
  • You also need messages or service calls between devices, encrypted between them with MLS.
  • Your existing database should stay the system of record, untouched.

Using PowerSync with Offline Protocol

PowerSync and Offline Protocol do different jobs, so an app can run both. PowerSync syncs the backend’s data to each device. Offline Protocol carries the shared working state between nearby devices between connections. When a device reaches the backend, the app writes the agreed result through its normal PowerSync path (local SQLite, the upload queue, then your backend), where your business rules decide what is accepted. Nothing connects the two automatically: the app decides which records each one carries, and should keep any one record on a single path so that the conflict rules stay predictable.

Frequently asked questions

Does PowerSync sync devices directly with each other?

No. PowerSync's documentation describes it as a server-client sync platform with no peer-to-peer syncing. Two devices see each other's changes once both have synced through your backend and the PowerSync Service.

Can Offline Protocol replace PowerSync?

Not for syncing a backend database to devices. Offline Protocol has no query engine and does not replicate Postgres, MongoDB or any other database. It replaces the part of a workflow where devices near each other share state or hand off work while the backend is out of reach.

Which databases does PowerSync support?

As of October 2026, the supported source databases are Postgres and MongoDB, with MySQL and SQL Server in beta, Azure DocumentDB in alpha and Convex marked experimental.

How does PowerSync handle write conflicts?

Your backend decides. Writes go to the local SQLite database and an upload queue, and an uploadData() function you write sends them to your own backend. A straightforward implementation gives per-field last write wins.

Is PowerSync open source?

As of October 2026, its client SDKs are Apache-2.0, and the service is source-available under the Functional Source License for self-hosting or provided under a commercial agreement in PowerSync Cloud. The self-hosted Open Edition is free.

How does Offline Protocol merge shared documents?

By a fixed rule per collection: last writer wins per map key, concurrent list insertions are kept, text merges by character, and counters add up.

Sources

Build it with Offline Protocol

The shared state guide shows replicated documents syncing between two devices with the internet disconnected, the merge rule for each collection type, and the two interruptions to test before relying on it.

Read the shared state guide