selfstore vs PouchDB
TL;DR: 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.
What PouchDB is
The venerable offline-first document database: a CouchDB-flavored store that runs in the browser and replicates with any CouchDB-compatible server. Mature revision-tree conflict handling, map/reduce views, a big ecosystem, a decade of production mileage. For a fleet of devices syncing through a CouchDB you are happy to operate, it remains a solid choice.
The architectural fork
PouchDB’s sync model has a server in it, by design: replication needs a CouchDB (or compatible) endpoint. That buys always-on convergence and multi-user documents, and it costs exactly what local-first tries to avoid: you now operate a database, manage its auth, and hold user data (cleartext, unless you build a crypto layer) on infrastructure you own.
selfstore’s model has no server role at all. Devices converge through a file on storage the user already has: their Drive, their Nextcloud, their disk. The merge runs on-device; what the storage sees is an AES-256-GCM encrypted blob. Nothing to operate, nothing that could leak cleartext.
| PouchDB | selfstore | |
|---|---|---|
| Sync rendezvous | CouchDB-compatible server | Any dumb storage the user owns |
| Who operates it | You (or a hosted Couch) | Nobody |
| Data at the rendezvous | Cleartext documents (by default) | Encrypted ZIP, opaque bytes |
| Conflict model | Revision trees, app resolves | HLC + strategies, conflicts journaled with both values |
| Data model | JSON documents + attachments | Named collections + files, plain JSON |
| Query | Map/reduce, find | None (snapshot model) |
| User-holdable backup | DIY | First-class, spec’d format |
| Size | ~46 KB gzip core | ~23 KB gzip core |
Use PouchDB when
- You want live server-mediated replication across many users and are willing to run CouchDB for it.
- Your data is document-shaped and benefits from revision history and views.
Use selfstore when
- The sync you need is one person’s devices (plus async sharing between a few people), and operating a database for that feels absurd.
- “The server must not be able to read it” is a requirement, not a nice-to-have.
- You want users to hold their data as a real file with an independently specified format.