selfstore vs TinyBase
TL;DR: 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.
What TinyBase is
A reactive store with a serious size discipline (a single-digit-kilobyte core, zero dependencies), fine-grained reactivity, and a large family of persisters - IndexedDB, OPFS, browser storage, SQLite in several runtimes, PGlite, Yjs, Automerge, and more - plus synchronizers over WebSocket and BroadcastChannel. Its documentation and test discipline are, frankly, a standard to aim at.
The design is that persistence is pluggable: TinyBase holds and reacts, the persister decides where bytes land. Encryption, a portable backup, a destination the user picks and the screens to connect one are outside that contract by construction.
What selfstore is
The opposite trade. It is not reactive - one subscribe and a stable state
snapshot - and it is not tiny. What it brings instead is the part TinyBase
leaves to you, decided and tested: AES-256-GCM over Argon2id, a
portable ZIP on an open spec, destinations on storage the user
already owns, a deterministic merge between their devices, and drop-in
widgets for the connect and share journeys.
| TinyBase | selfstore | |
|---|---|---|
| Reactivity | Fine-grained, everywhere | One subscribe + stable state |
| Size | A headline feature | Not a headline feature |
| Persistence | Many persisters, you pick | The loop, decided |
| Encryption | Yours to build | Built in |
| User-holdable backup | Yours to build | First-class, spec’d ZIP |
| Multi-device merge | Via a synchronizer you run | Serverless, via user-owned storage |
| Connect / share UI | Yours to build | Web components included |
Use TinyBase when
- You want reactive queries and metrics over local data, with a small bundle.
- Your persistence target is exotic and you would rather write an adapter than adopt an opinion.
Use selfstore when
- The hard part is not reactivity, it is durability: encryption, a real backup, a destination the user owns, and convergence between their devices.
- You would rather not implement, review and maintain the crypto path yourself.