Kasumi

Kasumi is an open-source key-value database written in Rust for multi-tenant applications. It can run as a standalone server or be embedded in a Rust application. Its document and index views reside in immutable memory generations; Kasumi's encrypted storage engine and OpenRaft provide persistence and ordered writes. JSON Schema validation, atomic batches, CAS, idempotency receipts, typed queries, and English/Japanese search share one authorization layer across Rust, native gRPC, and MCP.

The durable key-value format is implemented in the kasumi-kv crate. Its active goal tracks validation of the new engine for the first release.

The storage redesign goals target a large cache that keeps the whole working database in memory while it fits, then uses disk-backed reads above the configured bound. That redesign is not implemented or qualified; the resident-data limits described below still apply to current code.

Kasumi uses its own APIs; it does not implement the Redis protocol. See the standalone installation guide to run a local server.

Status: the first production release is being implemented and no source revision is release-qualified yet. The active release ledger records the current verified status and tracks the remaining implementation and acceptance gates. The first-release acceptance checklist lists the evidence the release still requires. Kasumi is licensed under Apache-2.0.

The September 5, 2026 v1 baseline is a historical prototype, not first-release evidence. It stored data in redb, which the first release has replaced with kasumi-kv. On that historical source, macOS and Linux passed 188 workspace tests, strict lint/formatting and live service checks. Its measured results cover all 15 required cases: 99,000 successful operations at 1, 100 and 1,000 tenants. They preserve source and executable identities, earlier failures and shared-host limitations. No Redis multiplier or production SLA is claimed. New first-release conditional transaction contracts, large atomic transactions/read leases, durable feeds and logical-history archives, chunked full backups, atomic schema activation, verified backup checkpoints, credential lifetime fences, incarnation credentials and restore lineage, exact planned source retirement, and independent custody storage extend that historical baseline. Their regression tests are development evidence. The first release still needs its own full platform, performance and endurance gates on its final source.

Deployment contracts

• Embedded/local: one voter. Successful writes follow durable persistence and complete local application. Reopening uses persisted bootstrap permissions.
• Replicated: three initial voters in independent failure domains, one Raft group per tenant. Writes require quorum persistence and local application; fresh reads establish a quorum barrier. Partitions never trigger a downgrade.
• Routing and operator metadata use a separate control group. Tenant policies remain inside their tenant group and are checked again during ordered apply.

Each successful batch publishes its matching document and index generation together. Cursors continue a historical snapshot for at most 60 seconds and are bound to identity, policy, incarnation, query, and leadership term; only each returned page is copied. Seek paging walks a unique index with stateless cursors for results of any size. Ordinary mutation receipts retain their original tenant, incarnation, principal and command identity permanently in encrypted point-addressed storage under explicit byte budgets. Snapshots and restores preserve these receipts and their original scope. Staged transactions keep permanent terminal identities, publish all effects in one generation and support up to 100,000 mutations within explicit byte budgets. Read leases provide bounded coherent point and ID-ordered collection pages.

Using Kasumi

use kasumi_client::prelude::*;
use serde_json::json;

let db = Kasumi::from_profile("/var/lib/kasumi/profiles/default.json").await?;
db.mutate(&MutationBatch::new().insert("invoices", "inv-1", json!({"status": "open", "amount": 42})))
    .await?;
let open = db
    .query(
        &QueryRequest::new("invoices")
            .filter(Filter::new().eq("/status", "open").gte("/amount", 10))
            .sort_desc("/amount")
            .limit(20),
    )
    .await?;

The same query is the JSON {"collection":"invoices","filter":{"/status":"open","/amount":{"gte":10}},"sort":["-/amount"],"limit":20} over native gRPC and MCP. See the query language and the API guide.

Workspace

Crate	Responsibility
kasumi-types	Exact JSON wire types, policy, commands, query expressions, limits
kasumi-kv	Kasumi's transactional durable key-value engine
kasumi-store	Encrypted records, Transit keys and leases, filesystem/S3 backups
kasumi-raft	OpenRaft 0.9.25, durable storage adapters and quorum barriers
kasumi-query	Offline schemas, persistent structured indexes, Tantivy/Lindera
kasumi-engine	Ordered application, shared API, bootstrap, restore, control metadata
kasumi-client	Shared native Protobuf and a secure typed query/transaction/read lease client
kasumi-transport	Shared TLS 1.3, mTLS, CA validation and server certificate pinning
kasumi-server	OAuth, TLS/mTLS, native Protobuf, MCP and administrative runtime
kasumi-bench	Reproducible latency, memory and recovery measurements across API layers

Rust 1.97.1 is pinned by rust-toolchain.toml. Linux is the production target; macOS supports development and embedded validation. Keep a warm Cargo target directory:

cargo test -p kasumi-types -p kasumi-kv -p kasumi-store -p kasumi-query
cargo test -p kasumi-raft -p kasumi-engine -p kasumi-server
cargo clippy --workspace --all-targets --no-deps -- -D warnings

See the Rust/native/MCP API guide, acceptance checklist, storage contracts, replication tests, and query semantics. Native Protobuf carries JSON as UTF-8 bytes so exact numbers do not pass through double.

Security boundaries

Network endpoints require TLS 1.3, users and agents present validated access tokens, and service/peer listeners require client certificates. Each tenant has its own customer Transit wrapping key. A replica independently probes every resident key version and fences access on denial or lease expiry. Persisted data and backups use authenticated envelope encryption with fresh nonces.

The host OS and embedding application are trusted. Returned plaintext cannot be recalled. Datasets and indexes must fit configured RAM budgets; Kasumi does not silently evict or spill to disk. Hardened hosts must disable plaintext swap and process dumps. Restore uses an empty target, creates a new incarnation, and remains suspended until explicit activation.

Redis compatibility, cross-tenant transactions, and intra-tenant sharding are outside v1. Benchmarks must distinguish a raw hash-map lookup from an authorized database read and from durable local or replicated writes.

See administrative commands, operations and recovery, and benchmark reproduction for the implemented workflows.