ZeBridge delivers to the client the (PG) enabled tables, replicates the schema locally (SQLite, PGLite, DuckDB tables), seeds them, and handles Postgres supported migrations. Local mutations are optimistic, durably queued (locally) and on (re)connection submitted to Postgres for the authoritative decision, and then CDC are echoed back with a verdict.

ElectricSQL is a Postgres-to-client read synchronization engine. It can operate without a local SQL database: it streams selected data as shapes and the selected rows can be maintained as JS objects or maintained by the dev as materialised into a local database. The reverse flow is implemented by the application and its backend API; libraries can add optimistic updates and offline write handling. Electric then synchronizes the resulting Postgres changes back to clients.

You also have PowerSync: it synchronizes the backend data into a local SQLite database using a schema supplied by the application. By default, records are stored as JSON and exposed through SQL views. It also offers native SQLite storage: managed tables, currently in alpha, are created and migrated automatically, while raw tables require developer-managed creation and migrations. Local writes take effect immediately and enter a durable upload queue. The SDK invokes a developer-provided uploadData() function to send those writes to the application’s backend API, which validates and applies them to Postgres. Authoritative changes then return through PowerSync’s synchronization stream.

In conclusion, ZeBridge is therefore closer to PowerSync in its local database and queued-write model, but the responsibilities differ. ZeBridge delivers server-derived schemas and integrates mutation submission and verdict handling. PowerSync manages local SQLite and the upload queue while the application supplies its client schema and backend write logic. Electric focuses on distributing Postgres changes, leaving client storage and the write path to the surrounding application stack.