Enterprise storage backend Enterprise only
MatrixDB: eventually consistent KV for high-throughput serving.
MatrixDB is the enterprise, Redis-compatible, multi-tenant KV database used alongside TemporalStore for hot sessions, profile KV, cache metadata, large scans, and exports — where scale and throughput matter more than transactional strictness.
The tradeoff
Trade strict ordering for throughput — on purpose.
Not every key deserves a transaction. A live session's scratch state, a user profile blob, an LMCache entry — these are read and written constantly, and it is fine if a replica is a few milliseconds behind. Forcing that traffic through a strongly consistent store would cap throughput and waste the coordination budget on data that does not need it.
MatrixDB takes the other side of the tradeoff. It relaxes to eventual consistency so writes acknowledge fast and reads spread across replicas, which is what lets it absorb very high QPS per tenant. What you get in return:
- High throughput at scale. Very high QPS with tenant isolation for hot sessions and profile state, growing with the serving fleet rather than a fixed replica set.
- Redis-compatible. Familiar KV APIs, so teams already on Redis-style access migrate with little rework.
- Multi-tenant. Isolate tenants across large profile, summary, cache, scan, and export workloads on shared infrastructure.
- Scans & exports. Database-style bulk reads, exports, and offline query paths that would be awkward against the hot serving path.
MatrixDB handles database-style KV so TemporalStore stays focused on temporal Context serving, and MatrixKV keeps the transactional truth. Right tool, right consistency.
Where it sits
A high-throughput KV plane beside the Context core.
MatrixDB runs alongside the Context core, not underneath it — the two serve different data shapes, so each scales on its own terms.
When to use which backend
MatrixDB is for scale, not transactional truth.
Choose MatrixDB when volume and latency dominate and a slightly stale replica is acceptable. If correctness must be exact, use MatrixKV; for the durable blocks under disaggregated serving, use MatrixObject.
| Backend | Best for | Consistency |
|---|---|---|
| Local disk / MatrixRaft open source | Self-hosted single-node or replicated serving. | Per-shard or consensus-replicated. |
| MatrixDB Enterprise | Hot sessions, profile KV, cache metadata, scans, exports. | Eventually consistent. |
| MatrixKV Enterprise | Metadata, leases, ownership, coordination. | Strong, transactional. |
| MatrixObject Enterprise | Shared durable blocks for disaggregated serving. | Durable shared storage. |
Enterprise storage family