What is Eelden?
Eelden is a multi-tenant-by-default database engine and query language, built clean-room in Rust (stdlib only, no unsafe outside one audited wasm allocator).
Most databases were designed single-tenant. Multi-tenancy got bolted on later with tenant_id columns or fleets of orchestrated databases. Eelden inverts that: the tenant is a first-class primitive of storage, language, and type system. Isolation is the zero-config case. Cross-tenant anything is the explicit, audited exception.
Founding bets
- Tenant = consistency boundary. Transactions, snapshots, forks, and residency are tenant-scoped engine operations — not app-layer orchestration. No cross-tenant transactions.
- Storage stores values. It does not enforce types or foreign keys at write time. Meaning lives in the language layer.
- Types are a language-layer construct. Schemas are code: diffable, versioned, CI-checked. Drift surfaces as
unknown, never silent coercion. - No hand-written migration files. Edit the schema; fingerprints drive lazy apply-on-touch. Destructive changes require
@breaking. - LSP-first language. Pipe-based queries where every stage has a known shape. Autocomplete and inline errors are design inputs.
- Versioned immutable pages. Copy-on-write forks, named snapshots, and lazy migration fall out of one storage decision.
Surfaces that ship today
| Surface | Role |
|---|---|
Engine (eelden CLI + crates/) | Durable local DB: pages, WAL, B-tree, query exec |
Studio (clients/studio) | Local web UI over eelden serve |
Playground (?local=1 / play.eelden.dev) | In-tab wasm engine (OPFS or mem) |
@eelden/client | Money types, tagged template, named-query codegen |
There is no SQL compatibility and no SQLite file-format compatibility.
Honest maturity
Eelden is pre-alpha. Status is the capability inventory. Everything else on this site describes what the code does now, with limits called out inline.