Enterprise storage backend Enterprise
Hot context state for the LLM context platform.
MatrixDB is MatrixArk's enterprise, eventually-consistent, Redis-compatible KV backend for the context platform. It holds the fast-moving state that context serving leans on — active session summaries, user and workspace profiles, and cache metadata — at high throughput, so TemporalStore stays focused on time-aware memory and prompt-time context.
The context platform serves prompts from a mix of durable temporal memory and fast-changing operational state. TemporalStore owns the first part: extraction, temporal writes, freshness, replay, and prompt-time context packs. MatrixDB exists for the second part — the hot context state that has to be read and updated on nearly every request but does not need transactional guarantees.
Why a separate hot-state backend
Active session summaries, current workspace state, per-user and per-tenant profile KV, and cache-eligibility metadata all change constantly and are read at very high QPS. Pushing that churn through the temporal write path would add write amplification and crowd out the memory timeline. MatrixDB absorbs it on an eventually-consistent path built for throughput.
Because MatrixDB is Redis-compatible, teams migrating an existing profile or cache layer into a MatrixArk deployment keep familiar strings, hashes, and TTL semantics while the backend handles distributed placement, persistence, tenant isolation, and elastic scale underneath. The point is not a general-purpose database — it is the enterprise hot-state tier that keeps context serving fast.
What lives in MatrixDB
- Hot session state — active session summaries, latest workspace state, in-flight context handles.
- Profile KV — per-user, per-tenant, and per-workspace attributes the context path reads before assembling a prompt.
- Cache metadata — prompt-section ids, cache-eligibility flags, source freshness, and invalidation hints for LMCache-style reuse.
# Profile KV read on the context path (per prompt).
HGETALL profile:company_a:user_918
# Active session summary, refreshed as the session moves.
SET session:sess_44c1:summary "..." EX 3600
HSET session:sess_44c1 workspace project_1 last_scope "company_a|platform|project_1"
# Cache metadata for prefix reuse.
HSET ctxcache:pack_7731 eligible 1 source_ver 913 ttl 900Where MatrixDB sits under the context platform
Hot state and cache metadata behind the serving core — not on the transactional path.
MatrixDB serves the eventually-consistent hot state the context path touches on every request; MatrixKV protects the small strongly consistent records; MatrixObject holds durable context data.
When to use which backend
TemporalStore serves context in every deployment. The durable and hot tiers depend on scale.
| Backend | Tier | Use it when |
|---|---|---|
| Local disk | Open source | Single-node, dev, edge, and self-hosted context footprints where one node owns its storage. |
| MatrixRaft | Open source | Replicated high availability for context state without a shared-storage tier. |
| MatrixObject Enterprise | Durable shared | Disaggregated, concurrent read/write, elastic capacity for durable context data at five-nines. |
| MatrixDB Enterprise | Hot state | High-throughput hot context state, profile KV, and cache metadata on an eventually-consistent, Redis-compatible path. |
| MatrixKV Enterprise | Transactional | Small strongly consistent metadata and coordination the context path must trust before acting. |