Decision guide
Which backend serves which context job.
Application teams should not have to decide whether a request belongs in TemporalStore, MatrixDB, or MatrixKV before they can build. They ask MatrixArk for context, memory, replay, hot state, or committed truth; MatrixArk routes the workload to the backend that serves it best — and TemporalStore covers most of it on its own.
The short answer
Start with TemporalStore. Add an enterprise backend only when the context path needs something it does not provide.
| Backend | Reach for it when the context is… | Why |
|---|---|---|
| TemporalStore first | Time-aware memory, session timelines, prompt replay, freshness counters, temporal windows, long behavior sequences, latest-value context, and most prompt-time context state. | The open-source serving core covers the large majority of context jobs by itself. |
| MatrixDB Enterprise | High-throughput hot session and profile state, cached retrieval results, and cache metadata — read and updated on nearly every request, where eventual consistency is fine. | A Redis-compatible hot-state tier absorbs the churn so the temporal path stays focused on memory. |
| MatrixKV Enterprise | Low-volume, high-importance records: permissions, document versions, leases, approvals, ownership, and committed actions. | Strong consistency for the small set of records where a stale or duplicate read would make an agent unsafe. |
How MatrixArk routes a request
One context API in front; the right backend behind it, chosen by the shape of the state.
The boundaries stay explicit so online context never collapses into one overloaded store: temporal memory on TemporalStore, eventually-consistent hot state on MatrixDB, strongly consistent truth on MatrixKV.
Route temporal context to TemporalStore
Many context deployments never need a separate KV backend, because the core question is temporal: what happened, what is latest now, what changed, what should be replayed, and what belongs in the next prompt? TemporalStore serves time-aware context, temporal windows, and latest values together, backed by low-latency processing, a multi-tier cache, and durable storage.
- Session timelines and tool-call history.
- Prompt replay and exact context-pack reconstruction.
- Open commitments, memory deltas, and stale-memory detection.
- Freshness counters, time windows, and long behavior sequences.
- Cache-eligibility signals and source-validity metadata tied to temporal context.
Route hot state to MatrixDB when scale demands it
MatrixDB earns a place when the context path leans on fast-changing operational state read at very high QPS — active session summaries, per-user and per-tenant profile KV, cached retrieval results, and cache metadata. Its Redis-compatible surface lets teams migrate an existing profile or cache layer in without rewriting access patterns, while the backend handles placement, persistence, and tenant isolation. If the value is still primarily time, order, and replay, keep it in TemporalStore.
Route committed truth to MatrixKV only where needed
MatrixKV is usually not required for context management. It should not carry every memory, profile, or cache value — only the smaller set where a stale read, duplicate ownership, or partial commit would make an agent or workflow unsafe: permissions, document versions, approvals, leases, ownership, and committed tool actions.
A practical rollout
- Expose one MatrixArk context API to application teams.
- Route time-aware context, memory, replay, counters, and sequences to TemporalStore.
- Add MatrixDB for high-throughput hot session and profile state and cache metadata.
- Add MatrixKV for the low-volume records that need strong consistency and committed visibility.
- Keep the boundaries explicit so online context does not collapse into one overloaded database.
Teams stay infrastructure-agnostic: they ask for context and let MatrixArk pick the backend. The serving core is open source at temporalstore.ai; MatrixDB and MatrixKV are the enterprise backends that extend it when scale and correctness demand more.