Alpha software — APIs may change

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.

End-to-end encryption: keys stay on devices, encrypted data flows to servers
Zero-trust storage
Server breach yields ciphertext

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.

Offline-first UX
Work without network

Create and edit locally. Metadata-first reconciliation syncs only what changed — bandwidth proportional to delta, not total size.

Collaboration
Conflict-free merges

Automerge CRDTs ensure concurrent edits converge automatically. Order-independent sync — entries can arrive in any sequence.

Why MindooDB?

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.

✅ Choose MindooDB when:
  • 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
❌ Consider alternatives when:
  • 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
Adoption effort

MindooDB is designed for progressive adoption. Start local-only and add sync when ready — no rearchitecting required.

Local-only

Hours. npm install mindoodb, create a tenant, open a DB, and start storing encrypted documents. No server needed.

Client-server sync

Days. Implement 2 auth endpoints + 3 sync endpoints. The reference server is included as a starting point.

Advanced topologies

Incremental. Add P2P, relay nodes, or Bloom filter optimization later — same protocol, no code changes.

Quick comparison
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

See detailed comparison →

How it works

Servers can sync & store — but cannot read

Keys stay on devices
Clients keep private keys; server stores encrypted blobs; sync exchanges missing encrypted entries.
Clients encrypt before sync. Servers store ciphertext. Sync exchanges only the encrypted entries you’re missing.
  • 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
Protocol guarantees

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.

Sync invariants
  • 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 by contentHash
  • Immediate revocation — enforced at challenge generation and token validation; no stale-token window
Sync performance
  • 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
Error handling & resilience
Auth failures

Challenge-response with Ed25519. Expired tokens trigger automatic re-authentication. Revoked users blocked at both challenge and token layers.

Network failures

Built-in exponential backoff for transient errors. Resumable cursor-based sync picks up where it left off after disconnects.

Data integrity

Every entry is Ed25519-signed by its creator. Append-only stores with hash chaining detect tampering at any relay hop.

Differentiators

Security guarantees without losing UX

Signed, tamperproof history
Append-only, cryptographically chained history for auditability and integrity.
Fine-grained access
Named keys enable need-to-know access control for sensitive documents.
Encrypted attachments
Chunked uploads, streaming reads, and tenant-wide deduplication.
Time travel
Retrieve document state at any timestamp and traverse full history.
Virtual Views
Hierarchical categorized views with totals (Domino/Notes-inspired).
Sync anywhere
Peer-to-peer, client-server, and hybrid deployments using the same primitives.
Proof in 60 seconds

Copy-pasteable examples

These snippets are derived from the MindooDB test suite to stay aligned with real usage patterns.

Deployment topologies

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.

Client-Server

Standard sync with a central server. Simplest deployment. Start here and scale later.

Peer-to-Peer

Two devices sync directly over LAN, WebRTC, or Bluetooth. No server dependency. Same pullChangesFrom/pushChangesTo API.

Relay / Passthrough

Data flows through nodes that cannot decrypt it. Sync operates on encrypted metadata — relay nodes never need keys.

Store Chaining

A node forwards sync requests to another remote store for edge caching, access control boundaries, or multi-hop distribution.

Mesh

Multiple peers sync with each other. Entries deduplicate automatically. CRDT convergence guarantees consistency.

Multi-Party

Different participants hold different keys. A hospital server syncs patient records it cannot read — trust is at the key level, not the network level.

Trust & transparency

Production readiness & trust signals

Current status

MindooDB is alpha software — APIs may change without notice. Core functionality is stable and tested, but we recommend thorough evaluation before production use.

What's stable
  • Core encryption and sync protocols
  • Document CRDT operations
  • Virtual Views and indexing
  • Attachment storage
What may change
  • API method names and signatures
  • Configuration options
  • Internal data structures
Security & transparency
  • 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
Community

Active development, comprehensive documentation, and growing community. View on GitHub →