Comparisons, written to be fair
Every page below includes a "use the other tool when" section that we mean sincerely. A storage library you picked for the wrong job helps nobody, least of all us. Several of these are not rivals at all: a CRDT and selfstore solve different halves of the same app, and the pages say so.
| Tool | Category | Needs a server | User-holdable backup | End-to-end encrypted sync |
|---|---|---|---|---|
| selfstore | Persistence loop | No | Yes, spec'd ZIP | Yes |
| Browser storage | ||||
| localStorage | Key-value strings | No | No | No sync at all |
| raw IndexedDB | Storage engine | No | Build it yourself | No sync at all |
| Dexie.js | IndexedDB query wrapper | Only for Dexie Cloud sync | Build it yourself | Through the hosted service |
| browser-fs-access | File picker ponyfill | No | Whatever you write | Build it yourself |
| Client databases | ||||
| PouchDB | Document database | Yes, a CouchDB you run | Build it yourself | No: cleartext to your server |
| RxDB | Reactive database platform | Endpoints you run, for sync | Export utilities | Plugin, depends on setup |
| TinyBase | Reactive in-memory store | For its sync server, yes | Build it yourself | Build it yourself |
| Sync engines | ||||
| Zero | Server-backed sync engine | Yes, Postgres plus zero-cache | Not the model | No: your server holds the data |
| ElectricSQL | Postgres read-path sync | Yes, Postgres plus the sync service | Not the model | No: your server holds the data |
| CRDT runtimes | ||||
| Yjs | Sequence CRDT | For live collaboration, yes | Build it yourself | Build it yourself |
| Automerge | Document CRDT with history | For live sync, yes (a repo peer) | Its own binary document | Build it yourself |
| Local-first, encrypted | ||||
| Evolu | Encrypted local-first SQLite | A sync server (theirs by default) | The mnemonic restores it | Yes |
| Jazz | Local-first framework with sync server | Yes, a sync server | Not the model | Yes |
| Fireproof | Embedded verifiable ledger | Optional cloud for sync | Its own ledger format | Yes |
| remoteStorage | Bring-your-own-storage protocol | Yes, the user's own RS server | Files on their server | Not by default |
Browser storage
selfstore vs localStorage
localStorage is fine for a theme flag. The moment users would be upset to lose the data, it is the wrong tool.
selfstore vs raw IndexedDB
selfstore IS IndexedDB underneath. The comparison is really "the 500 lines you were about to write" vs "a library that already wrote them".
selfstore vs Dexie
Not rivals. Dexie is the best way to QUERY IndexedDB; selfstore is a persistence LOOP. Big queryable tables, pick Dexie. Whole-app durability with backups and sync, pick selfstore. Both together is a legitimate architecture.
selfstore vs browser-fs-access
browser-fs-access solves the picker: one call for open and save across browsers that do and do not ship File System Access. selfstore solves the loop the picker is a step in - what to write, encrypted how, merged with what.
Client databases
selfstore vs PouchDB
Both sync. PouchDB syncs to a CouchDB-compatible SERVER you run, cleartext to that server. selfstore syncs through dumb user-owned storage, end-to-end encrypted, with no server in the loop.
selfstore vs RxDB
RxDB is a database platform - reactive queries, many storage engines, replication to servers you bring, premium tiers. selfstore is deliberately smaller: the save/backup/sync loop, MIT all the way down, no server anywhere.
selfstore vs TinyBase
TinyBase is a reactive in-memory store with an adapter for every persistence backend, and a remarkable size budget. selfstore is not reactive and not tiny: it is opinionated about one thing TinyBase leaves open - the encrypted file the user owns.
Sync engines
selfstore vs Zero
Different problems wearing the same words. Zero makes YOUR server's data feel local - and needs that server. selfstore makes the user's data durable and portable with no server at all. If you have a Postgres, you probably want Zero.
selfstore vs ElectricSQL
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.
CRDT runtimes
selfstore vs Yjs
Not rivals, and the pairing is the point: Yjs merges concurrent edits losslessly, selfstore gives that document an encrypted home the user owns and no server. Storing Yjs updates in a selfstore file is a supported, tested pattern.
selfstore vs Automerge
Same relationship as Yjs: Automerge merges concurrent edits and keeps their history, selfstore gives the result an encrypted home the user owns. Automerge alone if you need history; both if you also need the backup.
Local-first, encrypted
selfstore vs Evolu
The nearest neighbour: both put the key in the user's hands and refuse to see the data. Evolu gives you SQL, a schema and a sync server (theirs by default). selfstore gives you a file the user owns and no server at all.
selfstore vs Jazz
Jazz is a platform: CoValues, per-value permissions, auth, real-time sync, end-to-end encryption - and a sync server, hosted or self-run. selfstore is a library that stops at the storage loop and needs nothing hosted.
selfstore vs Fireproof
Close in spirit - embedded, encrypted, no setup - and different in output. Fireproof's artefact is a verifiable content-addressed ledger; selfstore's is a documented ZIP that opens in any archive tool.
selfstore vs remoteStorage
Same conviction, one decisive difference. remoteStorage needs the user to HAVE a remoteStorage account somewhere. selfstore uses storage they already have - a file on their disk, their Google Drive, a WebDAV server, an S3 bucket.