selfstore vs ElectricSQL
TL;DR: ElectricSQL replicates part of YOUR Postgres to the client through a sync service you run. selfstore has no Postgres, no service and no server: the durable copy is the user's own encrypted file.
What ElectricSQL is
A sync layer that streams “shapes” - defined subsets of Postgres tables - out to clients over HTTP, with the sync service designed to sit behind a CDN and scale to many readers. The read path is the mature part; writes back to Postgres are something you wire yourself, which is a deliberate boundary rather than an omission.
It is a strong answer to “my app’s data lives in Postgres and I want the client to feel instant”, and it is a genuinely different bet from the server-authoritative sync engines around it.
What selfstore is
Not that bet at all. There is no Postgres to project, no shapes to define, and no service to deploy. The user’s device is where the data lives; the durable copy is an end-to-end encrypted ZIP on a destination they own; multi-device convergence happens by merging that file in the browser.
Both call themselves sync, and the word covers two different jobs: your data, brought closer to the user versus the user’s data, kept safe without you.
| ElectricSQL | selfstore | |
|---|---|---|
| Source of truth | Your Postgres | The user’s device |
| Infrastructure | Postgres + sync service | None |
| What syncs | Shapes (table subsets) | The whole app state |
| Writes | You wire the path back | Built in, merged deterministically |
| Who can read the data | Your server | Only the user |
| Scale target | Many clients on shared data | One person’s devices, small groups |
Use ElectricSQL when
- Postgres is already the system of record and you want reactive local reads.
- Data is shared across users and the server must arbitrate.
Use selfstore when
- There is no server to project from, and adding one would mean acquiring the hosting, the migrations and the responsibility for someone else’s data.
- The user should be able to take their data and leave, as a file.