Different architectures, different ownership boundaries.

PowerSync Cloud is the documented setup path, and Open Edition or Enterprise can be self-hosted so the sync service stays on machines you run beside your own database.

PowerSync Cloud stores and relays synced buckets.

Electric Cloud is documented as the simplest host, and the same sync service can run from the official Docker image against your own Postgres, including Supabase.

Cloud Zero is the recommended Zero-operated service, and a documented self-host of zero-cache keeps the SQLite replica on machines you run.

Either deployment stores a SQLite replica of the published Postgres data inside zero-cache.

The Supabase plugin syncs through the supabase-js client you create for your own project URL, and the docs show no Legend-operated relay.

The Supabase replication plugin syncs the client straight to your Supabase project and does not put a vendor sync server in that path.

RxDB Server is a separate product and this plugin does not use it.

WatermelonDB is only a local database and tells you to sync with a backend you operate, so application data is not stored or relayed by a Watermelon vendor server.

The Supabase persister reads and writes your own Supabase project over that project's REST and Realtime APIs, and the WebSocket synchronizer is a server process you start.

PartyKit, PowerSync, and hosted LibSQL persisters are separate third-party services.

Triplit Cloud stores and relays application data, and the docs also describe a server you deploy and operate yourself.

The CLI and create-instant-app use Instant Cloud by default, so application data is stored on Instant's servers unless you switch the API URI to a server you host.

Self-hosting on your own Postgres and object storage is documented.

Offline writes sync to the Cloud Firestore backend run by Google, and the docs describe no production server you host.

Your app calls Supabase directly, so the path stays first-party as long as you add no relay of your own.

PowerSync replicates an existing Supabase Postgres database and can check Supabase Auth JWTs, while client writes go back through supabase-js.

A separate PowerSync Service is required.

Electric can tail an existing Supabase-hosted Postgres database, and it does not use Supabase Auth or Storage for sync.

You run a separate Electric service.

Supabase can host the Postgres database Zero replicates, and Zero does not use Supabase Auth or Storage for sync.

Zero needs Supabase's direct connection, and IPv4 is a paid add-on.

syncedSupabase talks to an existing Supabase project through a supplied supabase-js client, including Postgres tables and Realtime, and Auth is whatever session that client already has.

Official docs do not document Supabase Storage.

replicateSupabase syncs RxDB collections with tables in an existing Supabase Postgres project through supabase-js, and the guide uses that project's anon key.

The plugin docs do not cover Supabase Storage.

WatermelonDB is only a local database and tells you to bring your own backend, with no official Supabase integration.

The Supabase persister uses an existing project's supabase-js client but stores the whole TinyBase store as one JSON row, not your relational tables.

You create the table yourself.

Triplit documents a Supabase Auth integration so the Triplit server can accept that project's user JWTs, while the rows themselves stay in the Triplit database.

This uses neither the Supabase project's Postgres tables nor its Storage, and application data still moves to Triplit.

Instant stores application data in its own multi-tenant database or in a self-hosted Instant database, and the docs do not connect that data to an existing Supabase project.

Instant's backend uses PostgreSQL internally, but it is Instant's own database.

The Firestore client uses Cloud Firestore, and Supabase's official Firebase wrapper only reads Firestore into Postgres as foreign tables rather than running against an existing Supabase project.

Supabase also documents a one-time copy of Firestore data into Postgres.

Rows live in your tables because your code reads and writes them through supabase-js.

Every client connects to a PowerSync Service that runs beside the source database, either in PowerSync Cloud or self-hosted.

The sync engine is a separate Elixir HTTP service that connects to Postgres and that application clients call.

Electric Cloud can host that service.

zero-cache is a required server that holds a SQLite replica and talks to your query and mutate endpoints.

Cloud Zero can operate zero-cache for you.

The plugin calls the Supabase client from the app, and the docs do not require any extra sync server or service process.

Clients replicate straight to Supabase, and the plugin page says no self-hosted sync server is required.

The built-in sync adapter requires two HTTP endpoints that you run, so a sync service besides the database is required.

Those endpoints can live in an existing app server.

The Supabase persister talks only to Supabase Realtime and the REST API, while the WebSocket synchronizer needs a WsServer process you run.

A Cloudflare Durable Object can host that WebSocket server.

Rows live in a Triplit server, next to (not inside) Supabase.

You still run that server yourself or use Triplit Cloud.

Instant is its own backend, with sync servers that run beside its database.

Instant Cloud runs those servers for you.

Firestore is a separate Google backend, not a layer on Supabase.

Your app talks to Supabase directly, so no extra service is needed unless you add one.

PowerSync verifies the user's Supabase JWT directly, and the client takes that JWT from the Supabase client library.

Enable Use Supabase Auth, or set client_auth.supabase to true.

Documented sync auth is a proxy you build or a gatekeeper that mints a shape-scoped token, not the user's Supabase JWT used directly.

Supabase is named only as a place to run that gatekeeper edge function.

You pass a user id from whatever auth provider you already use, and Zero forwards cookies or a generic bearer token to query and mutate endpoints you authenticate.

The auth page never names the Supabase session.

Sync runs through the supabase-js client the app passes, so it carries the user session and JWT.

The plugin uses the official supabase-js client with the anon key and tells you to restrict rows with RLS policies that check auth.uid().

Sync is two functions you write against your own endpoints, and the docs describe no Supabase Auth session or JWT support.

Checking a Supabase JWT inside those endpoints would be application code, not a documented library feature.

The Supabase persister uses the supabase-js client you pass, and the docs tell you to gate that table with the signed-in session through auth.uid() row-level security, with no second login.

That session applies to the persister and Supabase Realtime.

The Triplit server verifies an external JWT, and the Supabase guide has the client sync with the Supabase access token itself.

You still set EXTERNAL_JWT_SECRET to the Supabase signing secret or public key.

Sync uses Instant's own refresh token after an Instant sign-in, and the auth docs document no Supabase Auth path.

The Clerk path calls signInWithIdToken, and Instant then creates its own long-lived session.

Firestore trusts Firebase Auth, so a Supabase login needs your server to mint a Firebase custom token; no direct Supabase JWT path is documented.

Custom-token sign-in is a separate auth exchange you have to build.

supabase-js attaches the user's session to each request, so you build no second auth system.

Built-in attachment helpers document Supabase Storage as a file store and the demos use it, while you still implement the upload and download adapter.

Several SDK helpers are marked alpha.

Not documented in Electric's official sources as of October 2026.

Not documented in Zero's official sources as of October 2026.

Not documented in Legend-State's official sources as of October 2026.

Not documented in RxDB's official sources as of October 2026.

The sync payload is raw record creates, updates, and deletes, with no upload, download, or attachment feature.

Persistence to Supabase is a text column in a table you create, and the docs describe no built-in attachment sync.

Triplit documents server disk storage and client IndexedDB or memory storage, and no file sync through Supabase Storage.

Files go through Instant Storage and the $files namespace, with no built-in sync through Supabase Storage.

Self-hosted Instant uses an S3 or MinIO bucket behind Instant's storage API.

Firebase uploads files to a Cloud Storage bucket it manages, and the docs describe no sync through Supabase Storage.

Cloud Storage for Firebase is a separate Google product from Firestore.

Storage is reachable from supabase-js, but you design and maintain the upload queue, the retries, and the link between files and rows.

Writes that reach Postgres through the Data API are authorized by RLS under the user JWT, but downloaded rows are chosen by Sync Streams.

Sync Streams do not apply to uploads.

Read authorization is an HTTP proxy or gatekeeper in front of shape requests, not Postgres RLS under the end user's JWT.

Electric does not sync writes, so it also does not authorize writes through RLS.

Reads and writes are authorized in your query and mutator code, and Zero does not use a Postgres RLS permission system.

Reads and writes go through the supabase-js client and its user session, so RLS applies.

The docs never say RLS or JWT, and the example only shows an anon-key client.

The Supabase guide tells browser clients to use the anon key and to write RLS policies that check auth.uid(), so each synced read and write is authorized as that user.

You must write the policies yourself.

The sync protocol treats the server as the source of truth and never mentions Postgres RLS or the end user's JWT.

Your own backend could enforce RLS.

Supabase persister reads and writes are denied until a Postgres RLS policy allows them, and the docs show policies aimed at the authenticated role and auth.uid().

RLS sees one JSON row, not each cell.

Authorization is Triplit schema filters on the client's JWT, and the documented server stores data in SQLite, LMDB, or memory, outside the reach of Postgres RLS.

External JWTs, including Supabase Auth, can be verified by the Triplit server.

Every read and write is checked by Instant's CEL permission rules, not by Postgres row level security under the end user's JWT.

Every mobile and web request is checked by Cloud Firestore Security Rules, which can read Firebase Authentication state, and the docs do not use Postgres row level security.

Rules can read request.auth when the app uses Firebase Authentication or Identity Platform.

supabase-js requests carry the user's JWT, so your policies apply as long as sync never uses a service-role key.

Each stream query limits the rows downloaded for a table, while uploads, conflicts, and deletes follow your backend write policy.

The documented backend default is deletes-win and per-field last write wins.

Electric syncs reads out of Postgres only, so write direction, conflicts, and deletes are not sync settings, while a shape can still filter the rows of one table.

A publication and read permissions can limit which tables and rows each client receives, but conflicts and deletes are mutator code rather than per-table sync settings.

Each syncedSupabase call can choose actions, a row filter, and a soft-delete column, and the plugin docs do not include a per-table conflict resolver.

actions and fieldDeleted can also be set globally with configureSyncedSupabase.

Each replicateSupabase call can filter rows, name the soft-delete column, and set pull and push, while conflicts stay on the Sync Engine's per-collection handler.

Hard deletes are unsupported.

The only per-table hook is conflictResolver, while sync itself runs for the whole database and the pull must include every collection.

There is no per-table read-only flag or per-user row subset.

The Supabase persister saves the whole store as one JSON row, so direction, row subset, conflicts, and deletes are not per-table settings.

Separate WebSocket paths can isolate whole stores, not tables inside one store.

Each collection has its own read, insert, update, and delete filters, so read-only versus read-write and the rows a role can see are per collection.

Conflict handling is one last-writer-wins register per attribute for every entity, documented on the FAQ, not a per-collection option.

Each namespace has its own view, create, update, and delete rules, and a view expression limits which entities a query can return.

Omitted rules default to allow.

Security rules match a collection path and split read into get and list and write into create, update, and delete, with conditions on document fields.

Rules are not filters: a query that might return a forbidden document fails as a whole.

You can code a different rule for each table, but you design, store, and maintain those settings yourself.

The service has a generic Postgres connector and also lists MongoDB, MySQL, SQL Server, Azure DocumentDB, and Convex connectors.

Postgres and MongoDB are GA, while MySQL and SQL Server are Beta.

Electric connects to any standard Postgres 14 or newer with logical replication, including hosts other than Supabase.

Other database engines are not documented.

Zero runs against Postgres 15 or newer with logical replication, including RDS, Aurora, Neon, Cloud SQL, and Docker, not only Supabase.

The same page says only Postgres is supported today.

Other official plugins sync to Keel, Firebase Realtime Database, a generic CRUD backend, or fetch, which covers databases other than Supabase.

There is no documented wire client for Postgres outside Supabase.

RxDB's sync engine also replicates over HTTP, GraphQL, CouchDB, Firestore, WebRTC, and other plugins, so a non-Supabase Postgres database is reached through your own endpoint.

Non-Supabase Postgres is your endpoint, not a built-in Postgres wire client.

The sync protocol is backend-agnostic, so the server you write can store data in Postgres or another database.

There is no Postgres client in the library.

Separate persisters save a store to PostgreSQL through the pg or postgres drivers, and others target SQLite, PGlite, LibSQL, and SQL Server.

Those database persisters are a different path from the Supabase REST persister.

The server can store its own data in SQLite or LMDB, and on Cloudflare in a Durable Object store, but it does not attach to an existing Postgres database.

A self-hosted Instant server requires PostgreSQL 17 with logical replication, so the backend can run on Postgres you operate, but only as Instant's own database.

The client cannot query an existing application schema or a non-Postgres database.

Cloud Firestore is a hosted NoSQL document database, and the official docs do not show it running on Postgres or on some other database you already operate.

A hand-built sync can talk to any backend, because you write both sides.

Each client reads and writes a local SQLite database whose schema tables mirror the synced source tables.

By default those tables are SQLite views over JSON documents.

The usual client holds shape rows as objects in memory, with a SQL database such as PGlite as an optional place to put them.

PGlite is a separate project, and the Expo guide says it does not yet work in React Native.

The web client stores sync state in IndexedDB, and the React Native adapters are key-value stores, not SQL tables that mirror the server.

Local persistence is a key-value plugin (localStorage, IndexedDB, MMKV, AsyncStorage, or the Expo SQLite kv-store), not relational tables that mirror server tables.

The Expo plugin imports expo-sqlite/kv-store, which is a key-value API on top of SQLite.

A SQLite storage exists, but it stores JSON documents and queries them with SQLite JSON functions rather than relational tables that mirror server tables.

The Supabase guide tells browsers to use localStorage or IndexedDB.

On React Native and Node the adapter is SQLite with tables and columns that match the local schema.

The web adapter is LokiJS on IndexedDB, not SQLite.

SQLite persisters can map tables into local SQL tables, but the Supabase and MergeableStore paths store one JSON document instead.

Tabular SQLite mode is unavailable for MergeableStore metadata.

The browser client persists in IndexedDB or memory, and the project says it does not provide a SQLite adapter in the browser.

React Native can use ExpoSQLiteKVStore, a key-value wrapper over expo-sqlite, not relational tables that mirror server tables.

The web client keeps a local triple store in IndexedDB, not a relational SQL database whose tables mirror server tables.

The on-device store is a cache of Firestore documents, using IndexedDB on the web and a persistent disk cache on Apple and Android, not SQL tables that mirror server tables.

You can mirror tables in local SQLite, but you write and migrate the schema mapping yourself.

The client API is SQL through methods such as execute and writeTransaction, not the supabase-js from().select().eq() chain.

Application code reads materialized shapes, or TanStack live queries over those shapes, not a supabase-js from().select().eq() builder.

Reads use named ZQL queries, not the supabase-js from().select().eq() builder.

Local reads use observables, while select() and eq() in the Supabase plugin are builders passed to the remote supabase-js client.

Local queries use Mango selectors, not the supabase-js from().select().eq() shape.

The Supabase plugin's queryBuilder does use PostgREST filters, and those run on the remote pull, not as the local query API.

Queries use Q.where and related clauses, not the supabase-js from().select().eq() chain.

Local queries are TinyBase query definitions with select, where, and join callbacks, not the supabase-js or PostgREST from().select().eq() chain.

The client builds queries with query(collection).Where(...), which is Triplit's API rather than supabase-js or PostgREST.

Reads use InstaQL objects such as { todos: {} }, which the docs compare to GraphQL, not to supabase-js or PostgREST.

Queries are built with collection references plus where, orderBy, and limit, which is not the supabase-js or PostgREST call shape.

You can imitate the call shape over a local database, but you build and maintain the query layer.

Local mutations are stored in the SQLite upload queue and the SDK retries them when connectivity returns.

The in-memory web VFS does not persist, so unuploaded writes in that mode are lost when the tab closes.

Electric does not sync writes, so offline writes survive a restart only if you build a persistent local-store pattern yourself.

The documented examples use valtio with localStorage, or a PGlite shadow table and trigger log that you maintain.

The fit guide says Zero does not support offline writes, and lists long periods offline as a reason not to use it.

With persist.retrySync, pending changes are stored locally and the engine keeps retrying them after an app restart until they sync.

Local writes stay in the local database, and the replication identifier is stored so replication resumes after the app reloads.

Durability depends on a persistent storage.

Local creates, updates, and deletes are stored in the database with a _status field and stay there until a later sync pushes them.

On web that store is LokiJS on IndexedDB.

The sync guide tells you to persist a store across browser reloads while offline and synchronize those changes after the device reconnects.

The default store lives in memory, so durability needs a persister.

Offline mutations sit in an outbox, and the IndexedDB storage adapter persists that outbox so a closed tab can upload the changes later.

The default storage is memory, which drops the outbox when the page refreshes.

Mutations are written to a persistent outbox before they are sent, and the web client keeps that local data in IndexedDB across refreshes.

With persistence enabled, the SDK still has writes from a previous app session and sends those pending writes after the app starts again.

The web SDK defaults to a memory cache, so a restart keeps writes only after persistentLocalCache or IndexedDB persistence is enabled.

You design the persistent queue, its ordering, and its retries yourself.

Sync Streams are SQL queries that choose which rows each user device downloads, such as rows owned by the authenticated user.

A shape selects one table with an optional where clause and column list, so each subscriber syncs a declared subset.

Shapes are single-table and immutable.

Query-driven sync sends each client the subset of rows named by that client's Zero queries.

The Supabase plugin can filter the listed rows, pass a Realtime filter, and with changesSince last-sync list only rows changed since the previous sync.

The filter is a query you write.

pull.queryBuilder can add PostgREST filters before the checkpoint query, so a client can pull a declared subset of rows.

Without a queryBuilder the pull covers the whole table, still limited by RLS.

Sync always runs for the whole local database, and the pull must return every collection rather than a declared subset of rows.

Your server can still omit rows it does not want this client to have, but the client protocol is not a per-bucket sync.

A Supabase persister writes the entire store into one JSON row, and clients on one WebSocket path synchronize that whole MergeableStore.

You can isolate users with separate WebSocket paths or separate store rows.

Clients subscribe to queries, and the server sends only the data for those subscriptions that the client does not already have.

Schema permissions can further limit which rows a token may read.

Sync servers track the queries a client has active and send new results to the queries a transaction affects, so a client does not subscribe to every row by default.

A query can still name an entire namespace.

A client caches documents it has already received from the backend, and the docs do not define a declared per-user, tenant, or bucket subset to keep in sync.

Security rules can reject reads the signed-in user may not make, which limits what enters the cache, but that is authorization rather than a sync partition.

You write the per-user pull queries and checkpoints that decide which rows reach each device.

Connected clients receive changes over an encrypted HTTP stream or a WebSocket, and the local SQLite database updates while online.

Live mode can long-poll or open a Server-Sent Events stream that pushes shape-log messages as they arrive.

The TypeScript client falls back to long polling if a proxy buffers the SSE response.

Clients keep a WebSocket connection open to zero-cache, as the auth guide notes in its cookie advice.

Setting realtime subscribes through Supabase Realtime and applies incoming changes to the observable immediately.

With live set to true, the plugin uses Supabase Realtime channels so server changes reach online clients as a push, not only by polling.

Pull and push of the document bodies still go through PostgREST.

synchronize() is a pull request followed by a push request, not a live push stream of server changes.

The app is expected to call synchronize() again when it wants new data.

With Realtime enabled, the Supabase persister receives other clients' changes as a push, and it polls only if you set an interval.

The browser client syncs by opening a WebSocket to the Triplit server, and the docs describe incremental real-time updates rather than polling.

Online clients receive other people's changes through Instant's sync servers as a live update, and the docs tell you to open another tab to see them without refreshing.

The client registers an onSnapshot listener, and the SDK invokes that callback again each time the document contents change.

You can subscribe to Realtime, but you design how its events become a safe local update.

Once the upload queue is empty, local rows are brought in line with server state, so a discarded write disappears without a dedicated rollback call.

The backend is told to return HTTP 2xx even when a write is rejected.

Electric does not accept client writes, so it does not answer a queued write with an applied or rejected verdict.

A 409 or must-refetch control message means the shape must be reloaded.

zero.mutate returns client and server results, including an error type, and a rejected server mutator reverts the optimistic local write.

A successful server result only acknowledges the mutation, and the Postgres change may not have replicated yet.

A failed update is thrown so the engine retries, and a successful update response is merged back into the observable.

The docs do not describe a per-write applied or rejected result with a reason, or an automatic rollback of a rejected local write.

When the master state has moved, the server rejects the push by returning the current master document, and the client conflict handler builds the next state.

The result is the master document, not a textual applied or rejected reason.

If any pushed record changed on the server since the last pull, the whole push is aborted, local changes stay unpushed, and the server returns an error.

That is one error for the batch, not an applied or rejected reason per write.

Not documented in TinyBase's official sources as of October 2026.

The docs say failed updates are rolled back and retried, and they document no applied or rejected payload with a reason for each queued write.

Permission filters can reject a write.

The official README says optimistic updates and rollbacks are handled for you, and it does not document an applied or rejected reason on each queued write.

Schema violations throw, and permission rules can deny create, update, or delete.

The client exposes hasPendingWrites until the backend acknowledges a change, and the docs describe no applied or rejected reason per queued write.

A failed transaction returns an error and does not write anything to the database.

You design the verdict format and the rollback of rejected local writes.

The documented simple backend keeps the last accepted write of each column, so concurrent edits to different columns can both survive.

Your backend must store the changed columns independently, or this becomes whole-record last-write-wins.

Postgres Sync does not merge concurrent edits to different columns, and any conflict behavior lives in the write API you build.

An update writes the fields you pass, and the docs describe no automatic merge of concurrent edits to different columns.

A custom mutator could implement that merge.

updatePartial sends only the changed fields plus the id, so an update does not have to replace the whole record.

That is a partial payload, not a documented merge when two clients edit different fields of the same row at the same time.

The CRDT plugin can merge concurrent document updates, including field operators such as $inc and $set, instead of replacing the whole document.

The default conflict handler keeps the whole master document and drops the fork.

When the same record changes locally and remotely, the client keeps the server version and reapplies only the columns changed locally since the last sync.

The strategy is per-column client-wins.

A MergeableStore stamps each cell update with its own hybrid logical clock, so later merges can keep the latest value of each cell rather than replacing the whole row.

Two writes to the same cell are last-write-wins.

Each attribute has its own timestamp, so concurrent edits to different attributes of one entity both remain, and the same attribute is last-writer-wins.

The FAQ calls the same-attribute case a last-writer-wins register using Lamport timestamps, not a semantic merge of two values.

Not documented in InstantDB's official sources as of October 2026.

Offline changes to the same document follow last write wins, so concurrent edits are not documented as a field-level merge that keeps both writers' columns.

update() can change chosen fields without replacing the whole document, and increment is applied on the server.

You choose and implement the merge rule, because a plain upsert overwrites the whole row.

writeTransaction runs several local SQL statements atomically, and each statement is queued as its own PUT, PATCH, or DELETE.

The server applies whatever uploadData sends.

There is no Electric API that submits several local writes as one all-or-nothing server batch.

Your own backend can still wrap its writes in a database transaction.

Several writes inside one mutator run in a single transaction, and a throw rolls the whole mutation back on both client and server.

There is no separate API that batches multiple named mutators.

debounceSet groups saves to cut update traffic, and the docs do not describe submitting several writes as one all-or-nothing server transaction.

RxDB documents that a single document write is the only atomic operation, so several writes are not one all-or-nothing batch.

Push batchSize sends several documents in one request, and each conflicted document is returned on its own.

The push endpoint must apply the whole changes object in one transaction and revert every change if anything fails.

The server has to implement that rule. _unsafeBatchPerCollection splits the local apply and the docs say it breaks transactionality.

A local transaction buffers several mutations and can roll them back in the store, but the docs describe listener batching rather than one all-or-nothing submission to the server.

The Supabase persister then saves the whole store as one JSON row, so one save is a single document write, not a multi-statement Postgres transaction of your tables.

client.transact groups several updates into one function, and the docs do not say that the server commits that group all-or-nothing.

db.transact submits several operations together, and the server commits them atomically or not at all.

Large transactions can time out.

A batch groups set, update, and delete calls into one atomic set that either all succeed or are not applied.

Transactions fail when the client is offline.

Postgres can apply a batch in one transaction, but you design how the client groups queued writes and reverts a refused batch.

The upload queue records PUT, PATCH, and DELETE only, and increment-style operations are described as a future version.

Electric does not document server-side increment or array add and remove operations, because it does not provide a write path.

A server mutator can drop to raw SQL, so an increment or array update can be written by hand.

There is no built-in increment or array add and remove operation.

The documented CRUD options send field values or changed fields, and they do not include server-side increment or array add/remove operations.

The update plugin's $inc and array operators change the local document, and the Supabase plugin then pushes the resulting document rather than a server-side field operation.

The CRDT plugin stores those operators so a custom backend could replay them.

The protocol sends created, updated, and deleted records, and it does not define server-side increment or array add/remove operations.

Not documented in TinyBase's official sources as of October 2026.

Set attributes are documented to accept concurrent additions and removals, which covers part of server-side collection edits, and numeric increment is not documented.

The FAQ says arrays are unsupported because concurrent pushes would overwrite the same index.

The documented writes are update, merge, delete, and link or unlink, and update replaces the attribute you send rather than applying a server increment or array operator.

Clients can send increment, arrayUnion, and arrayRemove field operations, plus a server timestamp that records when the server receives the update.

You write the SQL functions that apply each operation and the client logic that queues them.

Bucket history is compacted and checked with checksums, so a long-offline client catches up incrementally, and a checksum mismatch re-syncs the bucket.

Compaction replaces old operations with MOVE and CLEAR markers.

A purged shape sends must-refetch, and the TypeScript client discards its local copy and syncs that shape again from scratch.

Zero says it is a poor fit for long periods offline and does not document retained client tombstones plus an automatic rebuild after a retention window.

If the Postgres replication slot is invalidated, zero-cache re-syncs its server replicas from scratch.

Hard deletes cannot be listed from Supabase, so the plugin uses a soft-delete flag that later syncs can see and remove locally.

The docs do not describe a tombstone retention window or automatic detection and rebuild of a client that was offline longer than that window.

Deletes are kept as a _deleted flag so a client that was offline can still pull the deletion later.

The docs do not describe a retention window or automatic detection and rebuild when a client was offline longer than that window.

Pull and push carry deleted ids, and the backend guide suggests keeping deleted rows marked DELETED=true so later syncs can see them.

The docs do not describe a retention window or automatic rebuild of a client that was offline longer than that window.

Sync changes record a deleted cell or row as null, but the docs describe no retention window or automatic rebuild.

A release note says the React Native MMKV persister preserves deletion tombstones.

Not documented in Triplit's official sources as of October 2026.

Not documented in InstantDB's official sources as of October 2026.

Deletes use delete(), and for a long-offline client the docs describe periodic cleanup of older cached documents and last write wins, with no tombstone retention window that forces an automatic rebuild.

You design delete tracking, retention, and the rebuild of clients that were offline too long.

A protocol overview describes buckets, checkpoints, checksums, and the streaming session, then points readers at the SDK implementations.

That page does not link a conformance test suite.

The shape HTTP API is published as an OpenAPI document, with a narrative page for offsets, live mode, and control messages.

No conformance test suite for Postgres Sync is linked from that page.

The mutators page describes an internal push protocol that your endpoint runs, with no published wire specification or conformance suite.

Sync is calls through supabase-js, and the docs do not publish a wire protocol specification or a conformance test suite.

The sync engine page specifies the pull, push, checkpoint, and conflict behavior that a backend must implement.

No published conformance test suite for that wire protocol was found.

The Intro, Frontend, Backend, and Sync implementation pages specify the pull and push message shape and the conflict rules.

No conformance test suite for third-party servers was found.

The API publishes the synchronizer message types and calls them the basic synchronization protocol, and it does not publish a conformance test suite.

The same page says the enum is internal and opaque to applications.

Not documented in Triplit's official sources as of October 2026.

Not documented in InstantDB's official sources as of October 2026.

Google publishes the Cloud Firestore RPC reference, including Listen and a Write stream, and the pages reviewed do not include a conformance test suite for that protocol.

A typical custom implementation defines no published protocol and no conformance suite.

The SDKs include an attachment queue that uploads and downloads files for rows the app is watching.

Attachment helpers are Alpha on the feature-status page.

The Postgres Sync docs describe shape logs of table rows, with no built-in queue that syncs files with those rows.

The docs describe row queries and mutations, with no file queue tied to those rows.

The Supabase plugin syncs rows in a collection, and the sync docs do not describe a built-in queue that syncs files with those rows.

An attachments plugin stores files beside documents, and the sync engine can put attachment data on push and pull when the replication plugin supports it.

The docs say not every replication plugin replicates attachments, and the Supabase plugin page does not mention them or Supabase Storage.

The sync payload is created, updated, and deleted records, and the docs do not describe a queue that syncs files with those rows.

A store holds tabular cells and keyed values, and neither the Supabase persister nor the synchronizers document a file or media queue tied to those rows.

Not documented in Triplit's official sources as of October 2026.

Storage uploads a file, returns a $files id, and you link that id to another entity, so file metadata syncs as rows while the bytes use a separate upload call.

The upload is not documented as part of the mutation outbox.

A Firestore document is limited to 1 MiB of field data, and files are not synced with the documents that reference them through a built-in queue.

Cloud Storage for Firebase is a separate product with its own upload API.

You design the queue that links an upload to its row and survives restarts.

The attachment queue retries a failed transfer, and a transport that uses tus or S3 multipart can continue from the last confirmed offset.

Resume support belongs to the transport you implement.

The HTTP sync API documents shape requests, not resumable file uploads such as tus or chunked upload.

The mutator write path is a JSON mutation against Postgres, and the docs describe no resumable file upload.

The sync docs do not describe TUS or any other resumable chunked upload.

When attachment replication is supported, the push includes the full bytes of added or updated attachments, not a TUS or chunked resumable upload.

The sync docs do not describe TUS or chunked resumable uploads.

Not documented in TinyBase's official sources as of October 2026.

Not documented in Triplit's official sources as of October 2026.

Self-hosting requires the backend's object-storage role to manage multipart uploads, and the client upload guide does not document resume after an interrupted browser upload.

Cloud Storage for Firebase can pause and resume an upload, while Cloud Firestore document writes have no resumable upload of their own.

Pause and resume belong to the Storage upload task, not to the Firestore offline mutation queue.

Supabase offers TUS, but you wire the client, persist session URLs, and handle retries.

The attachment queue checks that local files exist and repairs missing ones, and the docs describe no content-hash check of downloaded bytes.

The shape protocol documents offsets, handles, and control messages, and no check of a downloaded file against a content hash.

The documented client store is IndexedDB or a key-value adapter, and no content-hash check of downloaded files is described.

The sync docs do not describe verifying downloaded files against a content hash.

Not documented in RxDB's official sources as of October 2026.

The sync docs do not describe verifying downloaded files against a content hash.

Not documented in TinyBase's official sources as of October 2026.

Not documented in Triplit's official sources as of October 2026.

Not documented in InstantDB's official sources as of October 2026.

Not documented in Firestore's official sources as of October 2026.

You store a hash with each file and check it after every download.

PowerSync publishes first-party React hooks and Vue composables.

React Hooks are GA, and Vue Composables are Beta.

Electric maintains first-party React hooks in @electric-sql/react, and no first-party Vue sync binding is documented.

The writes guide lists a third-party Vue optimistic-state helper.

React bindings ship in @rocicorp/zero/react, and the Vue bindings are the community package zero-vue.

First-party React and React Native bindings ship with the library, and the core can be called from any framework.

There are no first-party Vue composables.

First-party React hooks include useRxQuery, and a first-party Vue plugin exposes Vue shallow refs through VueRxReactivityFactory.

The Vue API is a reactivity factory, not a set of Vue composables.

First-party React bindings use withObservables to connect queries and records to components.

Vue is not a first-party binding.

First-party UI bindings exist for React, Solid, and Svelte, and the docs do not list a Vue binding.

The official repository lists first-party React, Solid, Vue, and Svelte support, and the release list publishes @triplit/vue.

The quick start names the React and Svelte bindings specifically.

First-party packages include @instantdb/react and @instantdb/vue, and the docs have a Vue 3 and Vite getting-started guide.

Firebase lists ReactFire and Vuefire for React and Vue and says those framework libraries are not official Firebase SDKs and are not covered by Firebase support.

You write the bindings between your local store and the UI framework.

The React Native SDK is listed generally available, and the Supabase guide includes an Expo-style React Native demo.

React Native Web Support and OP-SQLite Support are Beta.

The official Expo guide runs the TypeScript client and useShape in a React Native screen, and the native build pauses streams in the background.

PGlite does not yet work in React Native.

The React Native guide says Zero has built-in React Native and Expo support and shows ZeroProvider with an expo-sqlite or op-sqlite store.

Zero's fit guide still lists native mobile apps as a poor fit.

React Native is a first-party target, and the persist docs include an Expo SQLite storage plugin.

Version 3 is still labeled beta.

The official React Native database page documents Expo and React Native setup, including the React hooks and a SQLite storage.

The recommended Expo filesystem storage and the production SQLite storage are premium.

React Native on iOS and Android is a first-party target, with a SQLite adapter and installation steps.

The published installation page does not document Expo.

First-party persisters save a store with expo-sqlite, react-native-sqlite-storage, and react-native-mmkv, and React hooks come from the ui-react module.

The docs have a first-party React Native and Expo setup that uses @triplit/react-native hooks and an expo-sqlite storage provider.

The same page says the team has not tested bare React Native.

The docs include a first-party React Native and Expo getting-started guide using @instantdb/react-native.

The official JavaScript SDK lists Cloud Firestore on React Native with persistence excluded, and React Native Firebase is listed as a library that is not an official SDK.

The same environments page names Expo only for a Cloud Storage base-64 polyfill, not for Firestore disk persistence.

You choose and integrate a React Native SQLite store and its lifecycle hooks.

The Swift client SDK is listed generally available.

The documented clients are TypeScript and Elixir over the HTTP API, and no first-party Swift client is listed.

Zero says it only supports TypeScript clients, so there is no first-party native Swift client.

The client is a JavaScript library, and the docs do not ship a first-party native Swift SDK.

The vendor states that RxDB targets JavaScript and TypeScript runtimes and does not support a native Swift client.

iOS native code is the React Native bridge, and the sharing-database page tells Swift callers to use a bridging header rather than a Swift client SDK.

The project describes itself as a JavaScript and TypeScript store, and the docs do not ship a Swift client.

Not documented in Triplit's official sources as of October 2026.

The documented non-JavaScript surface is an admin HTTP API, and the SDK list has no Swift client.

The official Apple platforms SDK includes first-party Swift samples, and offline persistence is enabled by default on Apple platforms.

The offline page says this product is not available on watchOS and App Clip targets.

You build and maintain a Swift client separately from the web code.

The Kotlin client SDK is listed generally available.

The documented clients are TypeScript and Elixir over the HTTP API, and no first-party Kotlin client is listed.

Zero says it only supports TypeScript clients, so there is no first-party native Kotlin client.

The client is a JavaScript library, and the docs do not ship a first-party native Kotlin SDK.

The vendor states that RxDB targets JavaScript and TypeScript runtimes and does not support a native Kotlin client.

Android native code is the React Native bridge, and the docs do not ship a Kotlin client SDK.

Supported clients are JavaScript and TypeScript, including React Native, and the docs do not ship a Kotlin client.

Not documented in Triplit's official sources as of October 2026.

The SDK list includes JavaScript clients and a Python admin SDK, and it does not include a Kotlin client.

The official Android SDK includes first-party Kotlin samples, and offline persistence is enabled by default on Android.

You build and maintain a Kotlin client separately from the web code.

The default IndexedDB virtual file system shares one database across tabs on most browsers, and OPFSCoopSyncVFS adds Safari and iOS.

IDBBatchAtomicVFS does not support multiple tabs on Safari or iOS.

Not documented in Electric's official sources as of October 2026.

Tabs in the same browser share one synced client group, and the server rejects a group whose tabs are not the same user.

Not documented in Legend-State's official sources as of October 2026.

With multiInstance left at its default, events are shared across browser windows so each tab reacts to the same database changes.

SharedWorker storage, which runs one engine for every tab, is a premium plugin.

Not documented in WatermelonDB's official sources as of October 2026.

A BroadcastChannel synchronizer merges MergeableStores across browser tabs and workers.

Each tab keeps its own store object.

Not documented in Triplit's official sources as of October 2026.

The React guide tells you to open another tab and watch the same query update live, which shows server sync across tabs rather than one shared local engine.

The architecture essay says the web cache is IndexedDB.

The web SDK can share one IndexedDB persistence layer across tabs, including local document updates, when multi-tab persistence is enabled.

Without a tab manager the cache is single-tab.

You design tab coordination, such as a leader election or a shared worker, yourself.

The powersync CLI can create a Cloud instance, deploy Sync Config, and scaffold a local Docker stack.

The CLI is Beta.

The documented server install is a Docker image plus environment variables, not a CLI that loads migrations into your project.

An Electric Agents CLI exists for a different product and is not counted as Postgres Sync provisioning.

The documented command starts zero-cache for local development and does not install migrations or provision the server into your project.

Server setup is a SQL snippet the docs tell you to paste for timestamp and soft-delete columns, not a CLI that provisions your project.

The Supabase guide shows the SQL and client setup you apply yourself, and the repository scripts are build and test commands, not a provisioner for your project.

Server setup is a written protocol you implement, and the docs do not provide a CLI that installs it into your project.

The Supabase persister refuses to create or alter tables, and the docs tell you to apply a migration or use the SQL editor yourself.

create-tinybase scaffolds a client app.

The Triplit CLI pushes the schema in triplit/schema.ts to a running server and can start a local dev server.

triplit schema push applies Triplit's schema.

instant-cli plans a schema diff and applies it to your Instant app, and it can also push permission rules.

The CLI provisions Instant, not a Supabase project.

The Firebase CLI creates a Cloud Firestore database in the Firebase project and deploys that project's security rules and indexes.

The CLI provisions Google-hosted Firestore configuration.

You write and run the migrations for your own tables, triggers, and functions.

The vendor defines GA as production-ready for all main use cases, and Postgres, Open Edition, Sync Streams, and the main client SDKs are GA.

Attachment helpers are Alpha, the CLI is Beta, and some connectors and SDKs remain Alpha or Beta.

Electric 1.0 (March 2025) is GA with stable APIs.

The project status page says Zero has been generally available and fully supported since March 2026.

That same page still lists getting Cloud Zero to full public availability as 2026 work.

The v3 introduction says version 3 is in beta and may still change before the final release.

The same docs say the sync engine is the backbone of the Legend and Bravely apps.

Current docs and the 17.6.0 package do not label the product alpha or beta, and the project describes production use since 2016.

The open-source build is capped at 13 collections.

The homepage says the library is proven and has powered Nozbe Teams since 2017, and the roadmap calls it feature-complete and relatively API stable.

The version is still 0.x.

The current documented release line is v10, presented as a normal major release with breaking changes, not as an alpha or beta.

The releases page does not use the words generally available.

The published client is @triplit/client 1.0.x, and the current docs do not label the product alpha or beta.

The docs do not use the phrase generally available.

The vendor announced Instant 1.0 as the production release after describing the earlier build as a prototype.

Instant Cloud services continue until August 31, 2027.

Google's Cloud blog calls Cloud Firestore generally available, and the current offline-persistence guide presents the feature without an alpha or beta label.

The JS reference marks setIndexConfiguration, for local query indexes, as Public Preview.

A custom build has no vendor release, so its maturity depends on the tests and operations your team provides.