# selfstore vs PouchDB
Source: https://selfstore.dev/compare/pouchdb

PouchDB replicates documents to a CouchDB server you operate; selfstore converges encrypted files over storage the user already owns.

## 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](https://selfstore.dev/docs/peers)), 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](https://selfstore.dev/docs/format).

Map of this site for a model: https://selfstore.dev/llms.txt
Every page in one file: https://selfstore.dev/llms-full.txt