Local-first sync engines
An ElectricSQL alternative for apps without Postgres
Local data, offline reads, and a user who expects the same state on every device. Both keep the write path in your hands.
What ElectricSQL is
In its own terms.
A Postgres sync engine. Electric runs next to your database and exposes shapes, filtered subsets of a table, over HTTP; clients subscribe and hold the rows locally, and reads scale through ordinary CDNs. Writes go through your own API. Open source, with a hosted Electric Cloud.
Side by side
Where they part ways.
| s3nd | ElectricSQL | |
|---|---|---|
| What it is | A CLI, a library and React hooks over your own S3 bucket | Postgres read-path sync engine, shapes over HTTP |
| Where the data lives | Your bucket: S3, R2, MinIO, Scaleway, Wasabi | Your Postgres, replicated to clients |
| Both ends online at once | No. The code is redeemed later, until it expires | No |
| From inside your web app | Yes, through one route on your server | Yes |
| Accounts | None. The code is the whole handshake | Whatever your API requires |
| Hosting | Your bucket, plus your server when a browser takes part | Self-hosted or Electric Cloud |
| Price | Free. You pay your storage provider for a few objects that expire | Free; the cloud is paid |
| License | MIT | Apache-2.0 |
The differences
What actually changes.
Postgres versus a bucket
Electric needs a Postgres to sync from and is very good at it. s3nd needs an S3 bucket to store into and is very small about it. They solve the same user story at opposite ends of the infrastructure spectrum.
Live rows versus a snapshot
A shape is a live view that keeps updating. A snapshot is the whole local database at one moment, carried across with a code or rewritten as a backup.
A component to deploy versus a route to add
Electric is a service between Postgres and your clients. s3nd is a function in the API you already have, or a CLI with nothing deployed.
The decision
Pick the one that fits.
Pick ElectricSQL when
- Postgres is the source of truth and you want it on the client.
- Many users reading overlapping data, with live updates.
- A read path that scales through a CDN.
Pick s3nd when
- No Postgres, or no backend database at all.
- Move to a new device, backup, encrypted export: the one-shot cases.
- The smallest thing that works.
More comparisons
Tool by tool.
Put a file. Hand over the code.
Point it at the bucket you already pay for. Nothing to deploy, nothing to sign up for, nothing in the middle.
npm install -g @s3nd/clis3nd init --provider r2 --bucket drops3nd put ./anything.zip