Enterprise storage backends Enterprise
MatrixDB and MatrixKV behind the context platform.
TemporalStore serves LLM context everywhere. When a deployment needs more than one node's worth of hot state, or a handful of records that can never be wrong, two enterprise backends sit underneath: MatrixDB for high-throughput hot context state and profile KV, and MatrixKV for the small, strongly consistent records the context path must trust. They are storage backends for the context platform — not general-purpose databases to shop for up front.
You should not have to pick a storage engine to use MatrixArk. You integrate with one context surface — ingest events, compile context, get a token-budgeted context pack — and TemporalStore routes state to the right backend underneath. Most context tolerates eventual consistency: memory timelines, hot session state, cached summaries. A small slice cannot: permissions, approvals, leases, ownership. The two enterprise backends exist so both kinds of state get the guarantees they need without changing the API.
The split, in one sentence each
- TemporalStore — the serving core: time-aware memory, extraction, freshness, replay, and prompt-time context packs. Open source.
- MatrixDB Enterprise — high-throughput, eventually-consistent hot context state and profile KV read on nearly every request.
- MatrixKV Enterprise — strongly consistent, transactional records the context path must trust before and after it acts.
Where each backend sits
One serving surface on top; enterprise backends underneath, each for the state it is built for.
Application teams call one context API. TemporalStore stays the single serving surface; the enterprise backends handle placement, scale, durability, and consistency underneath.
MatrixDB: hot context state at scale
The high-throughput backend for the state the context path reads on almost every request.
MatrixDB is the enterprise backend for hot, high-volume context state: active session summaries, profile KV, cached retrieval candidates, and cache-policy metadata for prefix reuse. It offers Redis-compatible access for teams that already think in strings, hashes, and TTL state, but adds what a context platform needs at scale — persistence, scans and exports for repair and evals, tenant-aware placement and quotas, and cheaper storage for colder KV. It is tuned for throughput and eventual consistency, not for records that must have exactly one committed answer.
- Hot session summaries, profile KV, and ranked retrieval candidates read on the serving path.
- Cache-eligibility keys, reusable prompt-section ids, and invalidation hints for prefix reuse.
- Scans, exports, and nearline query for repair, analytics, and eval joins.
- Tenant-aware routing, quotas, and noisy-neighbor control across the context platform.
MatrixKV: records that cannot be wrong
The strongly consistent boundary the context path consults before and after it acts.
MatrixKV is deliberately small and separate from MatrixDB. It is not high-volume memory; it is the transactional boundary that keeps a few correctness-critical records trustworthy. Get these wrong and the model reasons over unauthorized, duplicated, or superseded context — a stale permission leaks data, a duplicate ownership record double-commits an agent action, a missed lease lets a paused worker keep writing.
- Before the prompt — permissions, source versions, and tenant policy checked before context enters the model.
- Before the action — idempotency keys, leases, approvals, and ownership committed before an agent mutates product state.
- After the action — committed outcome ids and timestamps TemporalStore references later for replay, audit, and stale-action blocking.
# Before the prompt: is this source visible to this user, at this version?
GET perm:company_a:doc_913:user_918 -> "read"
GET source:doc_913:visible_version -> 7
# Before the action: commit ownership + idempotency in one transaction.
TXN
SETNX lease:gpu_batch:owner worker_44 EX 30
SETNX action:appr_913:commit 1
COMMIT
# After the action: record the committed outcome for replay + stale-blocking.
SET outcome:appr_913 '{"status":"approved","ts":"2026-06-14T16:20:00Z"}'When to use which backend
TemporalStore serves context everywhere. Reach for a specific backend only for the state that demands it.
| Backend | Consistency | Use it when |
|---|---|---|
| Local disk | Single node | Dev, edge, and self-hosted context footprints where one node owns its storage. Open source. |
| MatrixRaft | Replicated | Replicated high availability for context state without a shared-storage tier. Open source. |
| MatrixObject Enterprise | Durable shared | Disaggregated, concurrent, elastic capacity for durable context data at five-nines. |
| MatrixDB Enterprise | Eventual | High-throughput hot context state, profile KV, and cache metadata read on nearly every request. |
| MatrixKV Enterprise | Strong / transactional | Small correctness-critical records — permissions, approvals, leases, ownership, timestamps — the context path must trust. |