selfstore vs Fireproof
TL;DR: 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.
What Fireproof is
An embedded database that starts with one call and no configuration, built on immutable, content-addressed data with cryptographic verification - a tamper-evident ledger rather than a mutable table. Encryption is end to end, and cloud connection is deferred until you want it, which is a positioning selfstore recognises immediately.
Where it aims differently is provability: the point of the ledger is that a third party can verify the history was not altered. That is real, and selfstore offers nothing like it.
What selfstore is
A storage loop, not a database. Plain JSON collections plus binary files, an IndexedDB working copy, and a merge that runs in the browser with no CRDT runtime.
The artefact is the clearest difference. Fireproof’s is its own ledger format, understood by Fireproof. selfstore’s is a real ZIP on a published spec: unencrypted it opens in any archive tool; encrypted it is still a valid ZIP holding the AES-256-GCM ciphertext, the cleartext parameters and a readme - never a mystery blob. The spec ships with a small reference reader in another language, so “you can leave” is a documented claim rather than a promise.
| Fireproof | selfstore | |
|---|---|---|
| Model | Immutable verifiable ledger | Mutable snapshot, LWW merge |
| History | Kept, verifiable | None |
| The artefact | Its own ledger format | A spec’d ZIP anything can read |
| Sync | Optional cloud | Storage the user already owns |
| Queries | Yes | None |
Use Fireproof when
- You need the history to be verifiable by someone who does not trust you.
- Content addressing and immutability are the properties you are buying.
Use selfstore when
- The user should end up holding a file they can open, copy and read in ten years without your software - and without ours.
- Destinations the user already has (a disk file, Drive, WebDAV, S3) matter more than a cloud designed for the library.