Decision Guide
MatrixArk can choose the right state engine so users stay infrastructure-agnostic.
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, prompt memory, replay, hot state, Redis-compatible access, query, or committed truth; MatrixArk can route the workload to the right backing engine.
The short answer
| Use | When it is enough | Why |
|---|---|---|
| TemporalStore first | Time-aware memory, temporal KV, latest KV, prompt replay, low-latency fetch and processing, multi-layer cache, persistence, freshness counters, temporal windows, long behavior sequences, and most prompt-context state. | MatrixArk can cover most context serving use cases with TemporalStore. |
| MatrixDB when needed | Redis-compatible multi-tenant database KV, online/offline/nearline KV, large profile and summary KV, cached retrieval results, LMCache metadata, hashes, TTL state, scans, exports, and tens of millions of QPS. | MatrixArk can route to MatrixDB when database features, Redis compatibility, tenant isolation, scale, cost, or query/export paths matter. |
| MatrixKV when needed | Low-volume but high-importance records: permissions, document versions, leases, ownership, workflow checkpoints, approvals, routing metadata, timestamps, and committed actions. | MatrixArk can route correctness-critical records to MatrixKV when transactional KV or strongly consistent data is required. |
Route temporal context to TemporalStore
Many LLM context systems do not need application teams to think about a separate KV database at the beginning, and many do not need one later. TemporalStore can serve time-aware context, temporal KV, and latest KV together, backed by low-latency processing, multi-layer cache, and persistent storage. If the core question is "what happened, what is latest now, what changed, what should be replayed, and what context should enter the next prompt?", MatrixArk can route that state to TemporalStore.
- Session timelines and tool-call history.
- Prompt replay and exact context-pack reconstruction.
- Open commitments, memory deltas, and stale-memory detection.
- Latest per-entity KV values that are part of prompt-time context.
- Freshness counters, time windows, long sequences, and event-heavy context.
- LMCache eligibility signals and source-validity metadata tied to temporal context.
The reason is simple: these records are more than isolated cache keys. Their value comes from time, ordering, filtering, replay, latest-value lookup, and request-time context assembly.
Route hot and nearline KV to MatrixDB
MatrixDB becomes useful when the product needs KV as a database, not only a context serving engine. These workloads need Redis-compatible APIs, multi-tenancy, elastic placement, tens of millions of QPS, large profile or summary KV, online/offline/nearline access, LMCache metadata or cache-control integration, cheaper persisted storage, scans, exports, repair, or joins into nearline workflows. If the value is still primarily serving, time, order, replay, latest context, and prompt assembly, keep it in TemporalStore instead.
timeline, replay, temporal memory MatrixDB
Redis-compatible database KV at scale Application
context pack plus current profile state
- Route large profile KV, summary KV, active sessions, cached retrieval results, and TTL state to MatrixDB.
- Route Redis-compatible migration paths to MatrixDB where applications already speak strings, hashes, or familiar KV semantics.
- Route LLM integration metadata to MatrixDB: LMCache keys, cache eligibility, reusable prompt-section ids, source freshness, and invalidation hints.
- Route persisted KV to MatrixDB when online, offline, nearline, scans, exports, repair, analytics, or training joins matter.
- Route to MatrixDB when eventual consistency is acceptable and tens of millions of QPS, scale, cost, and tenant placement matter more than strict transactions.
Route strong consistency to MatrixKV only when needed
MatrixKV is usually not required for context management. It should not carry every memory, every profile, every latest KV value, or every cache value. MatrixArk uses it only for the smaller, lower-volume set of records where stale reads, duplicate ownership, partial commits, or conflicting versions can make an agent, metadata path, or product workflow unsafe.
- Route permissions, document versions, approvals, locks, and workflow checkpoints to MatrixKV.
- Route routing metadata, partition ownership, leases, timestamps, and committed table state to MatrixKV.
- Route idempotency records and committed tool actions to MatrixKV where the system must not apply the same action twice.
- Keep high-QPS temporal timelines, latest context KV, giant profile hashes, and large eventually consistent serving state on TemporalStore or MatrixDB.
A practical rollout
- Expose one MatrixArk context API to application teams.
- Route time-aware context, prompt memory, replay, counters, and long sequences to TemporalStore.
- Route hot current-state KV, Redis-compatible migration, scans, exports, cheaper persisted KV, or nearline query to MatrixDB.
- Route low-volume strong consistency, ownership, permissions, leases, committed visibility, or transactional correctness to MatrixKV only as needed.
- Keep the boundaries explicit so online state does not collapse into one overloaded database.