Your Data. Your Keys. Your Control.
MindooDB is an end-to-end encrypted, offline-first sync database for secure collaboration — servers can store and sync, but cannot read. Works client-server, peer-to-peer and local-only. For browsers, NodeJS and React Native.
Keys stay on devices. Three independent encryption layers: AES-256-GCM at rest, per-user RSA in transit, TLS on the wire. Servers never see plaintext.
Create and edit locally. Metadata-first reconciliation syncs only what changed — bandwidth proportional to delta, not total size.
Automerge CRDTs ensure concurrent edits converge automatically. Order-independent sync — entries can arrive in any sequence.
When to choose MindooDB vs. alternatives
MindooDB is designed for applications where end-to-end encryption, offline operation, and multi-party collaboration are essential. Here's when it fits best.
- You need end-to-end encryption and cannot trust your hosting provider
- You require complete audit trails with cryptographic integrity
- You need offline-first operation for field or remote operations
- You collaborate across organizations and need fine-grained access control
- You need technical controls for compliance — encryption, signed audit trails, and coordinated data erasure that support HIPAA, SOX, GDPR, PCI-DSS programs
- You want simple backups without key exposure
- You need multi-party collaboration with different access levels
- You only need simple CRUD operations without collaboration
- You always have reliable network connectivity and don't need offline-first
- You don't need end-to-end encryption and can trust your hosting provider
- You have simple access control needs that don't require document-level encryption
- You need complex relational queries that don't fit document model
- You have very high write throughput that may challenge append-only stores
MindooDB is designed for progressive adoption. Start local-only and add sync when ready — no rearchitecting required.
Hours. npm install mindoodb, create a tenant, open a DB, and start storing encrypted documents. No server needed.
Days. Implement 2 auth endpoints + 3 sync endpoints. The reference server is included as a starting point.
Incremental. Add P2P, relay nodes, or Bloom filter optimization later — same protocol, no code changes.
| Feature | MindooDB | PostgreSQL/Firebase | Blockchains |
|---|---|---|---|
| End-to-end encryption | ✅ Yes (servers can't decrypt) | ❌ No (server-side keys) | ⚠️ Public by default |
| Offline-first | ✅ Built-in | ❌ Requires custom logic | ❌ Requires network |
| Audit trails | ✅ Append-only, cryptographically chained | ⚠️ Requires custom implementation | ✅ Immutable public records |
| Multi-org collaboration | ✅ Fine-grained access control | ⚠️ Server-side access control | ❌ All-or-nothing visibility |
| Performance | ✅ High (no consensus needed) | ✅ Very high | ❌ Lower (consensus overhead) |
| Data privacy | ✅ Private by default | ⚠️ Depends on server security | ❌ Public by default |
Quick links by role
Get started with code examples and API reference
Architecture, scalability, and deployment topologies
Protocol internals, sync semantics, and failure behavior
Compare alternatives, assess adoption effort and risk
How MindooDB supports HIPAA, SOX, GDPR, PCI-DSS
Servers can sync & store — but cannot read
- Sign every change (authorship + integrity)
- Encrypt before leaving the device (confidentiality)
- Append-only storage (audit trail)
- Content-addressed sync (transfer only what’s missing)
- Works client-server and peer-to-peer
Built for correctness, then optimized for speed
The sync protocol provides formal guarantees that hold across all deployment topologies — client-server, peer-to-peer, relay chains, and mesh networks.
- Completeness — after a full sync cycle, the client has metadata awareness of every remote entry
- Idempotency — every endpoint can be called repeatedly with the same input without side effects
- Order independence — entries can arrive in any sequence; CRDTs handle causal ordering
- Deduplication — entries identified by
id, deduplicated bycontentHash - Immediate revocation — enforced at challenge generation and token validation; no stale-token window
- Baseline sync — send known IDs, receive missing metadata; works for any dataset size
- Cursor scanning — page through remote metadata incrementally; constant request size regardless of total entries
- Bloom filter pre-check — probabilistic set summary eliminates 90–99% of exact existence checks
- Capability negotiation — start simple, enable optimizations later without protocol changes
- Snapshots — periodic CRDT snapshots prevent performance degradation from long histories
Challenge-response with Ed25519. Expired tokens trigger automatic re-authentication. Revoked users blocked at both challenge and token layers.
Built-in exponential backoff for transient errors. Resumable cursor-based sync picks up where it left off after disconnects.
Every entry is Ed25519-signed by its creator. Append-only stores with hash chaining detect tampering at any relay hop.
Security guarantees without losing UX
Copy-pasteable examples
These snippets are derived from the MindooDB test suite to stay aligned with real usage patterns.
Built for secure, collaborative applications
Same protocol, any network shape
Every topology uses the same ContentAddressedStore interface and the same sync protocol. Switching from client-server to peer-to-peer is a deployment decision, not a code change.
Standard sync with a central server. Simplest deployment. Start here and scale later.
Two devices sync directly over LAN, WebRTC, or Bluetooth. No server dependency. Same pullChangesFrom/pushChangesTo API.
Data flows through nodes that cannot decrypt it. Sync operates on encrypted metadata — relay nodes never need keys.
A node forwards sync requests to another remote store for edge caching, access control boundaries, or multi-hop distribution.
Multiple peers sync with each other. Entries deduplicate automatically. CRDT convergence guarantees consistency.
Different participants hold different keys. A hospital server syncs patient records it cannot read — trust is at the key level, not the network level.
Production readiness & trust signals
MindooDB is alpha software — APIs may change without notice. Core functionality is stable and tested, but we recommend thorough evaluation before production use.
- Core encryption and sync protocols
- Document CRDT operations
- Virtual Views and indexing
- Attachment storage
- API method names and signatures
- Configuration options
- Internal data structures
- Open source — Full codebase on GitHub
- Security audit — Documented in security audit docs
- Threat model — Assumes servers are compromised
- Cryptographic guarantees — Ed25519 signatures, AES-256-GCM encryption
Active development, comprehensive documentation, and growing community. View on GitHub →