Introducing MoltenDB: A Local-First, Pure Rust Database for the Browser and Server

#rust #nosql #typescript #database

First of all, apologies for being so blunt and straightforward right out of the gate, but I am super excited to finally share what I've been building.

After a lot of hard work juggling a full-time job and personal life, I'm thrilled to announce the Alpha release of my first major open-source project: MoltenDB.

MoltenDB is a JSON document database written completely in Rust. What makes it special is that it compiles to both a native server binary and a WebAssembly (WASM) module. This means you run the exact same query engine and use the exact same log format in your browser as you do on your backend.

⚠️ Disclaimer: This is currently in Alpha software. APIs might change, and it is not recommended for production just yet. But I am actively looking for developers to test it, break it, and provide feedback!

🏗️ The Architecture: Two Environments, One Engine
In the Browser (WASM + OPFS)

MoltenDB doesn't just store data in memory; it acts as a full document store running inside a Web Worker, ensuring zero main-thread blocking.

It persists data across page reloads using the Origin Private File System (OPFS).
It handles automatic log compaction based on record counts (every 500 inserts) or file size (> 5 MB).
- The entire engine is bundled into publishable NPM packages (@moltendb-web/core and the type-safe @moltendb-web/query builder).

On the Server (Native Rust Binary)

When running as a standalone backend, MoltenDB is built for speed and security.

It is an HTTPS-only server requiring TLS certificates and handles JWT authentication.
Data is encrypted at rest by default using XChaCha20-Poly1305.
It offers tiered storage (hot logs and cold logs with mmap reads) for large datasets (100k+ documents).
You can choose between async writes (50 ms flushes for high throughput) or sync writes (flush-on-write for zero data loss).
It includes a built-in WebSocket endpoint (/ws) that pushes real-time change events on every single write.

🔎 GraphQL-Style Querying over Plain JSON

One of my favorite core features of MoltenDB is how it handles data fetching. Instead of over-fetching full documents or maintaining a complex GraphQL schema, MoltenDB allows you to specify exactly which fields you want back via a simple JSON API.

Dot-notation works at any depth, so requesting "specs.display.features.refresh_rate" returns only that specific nested value.

Here is what a typical query looks like via HTTP:

POST /get
Content-Type: application/json
Authorization: Bearer <token>

{
  "collection": "laptops",
  "where": { "brand": { "$in": ["Apple", "Dell"] }, "in_stock": true },
  "fields": ["brand", "model", "price"],
  "count": 10,
  "offset": 0
}

Powerful Query Features:

Rich WHERE clauses: Support for $eq, $ne, $gt, $lt, $contains, $in, and more.
Cross-collection joins: Join related documents using dot-notation foreign keys at query time.
Inline references (extends): Embed data from another collection directly at insert time for O(1) reads later.
Auto-indexing: If you query a field 3 or more times, MoltenDB automatically builds an index for it, turning equality lookups into O(1) operations.
Document Versioning & Conflict Resolution: Every document automatically gets a _v (version counter), createdAt, and modifiedAt. Incoming writes with older or equal versions are silently skipped to handle conflicts.

🗺️ The Roadmap (and Anti-Goals)

As a solo developer, I'm moving at a sustainable pace to keep the architecture clean. Here is what is coming next:

Multi-Tab WASM: Implementing Leader Election so multiple browser tabs can share the OPFS engine seamlessly.
Mobile Native Modules: Compiling the Rust core via FFI/JNI to bring this local-first database natively to React Native and Flutter.
Robust Sync: Two-way delta sync between the browser and server.
Transactions: ACID multi-key writes (BEGIN, COMMIT, ROLLBACK).

What I will not be building:

To keep MoltenDB incredibly fast and lightweight, I am strictly avoiding bloat.

No Natural Language Queries (NLQ): While AI is trendy, baking NLQ or vector engines into MoltenDB would destroy the lightweight footprint of the WASM build.
No Heavy Data Transformations: Operations like map or flatMap belong in your application layer, allowing the query engine to focus purely on retrieving your data as quickly as possible.

🚀 Try It Out

You don't even need to install anything to try the WASM version.
👉 Try the Live Browser WASM Demo on StackBlitz

If you want to spin up the server locally, you can install it via Cargo: