MatrixDB
MatrixDB adds supporting hot and nearline KV to LLM context platforms.
TemporalStore remains the primary engine for LLM context management and prompt engineering. MatrixDB is added when the platform needs current-value KV around that context: hot profiles, active summaries, cached retrieval metadata, Redis-compatible hashes, TTL state, LMCache metadata, cache eligibility keys, invalidation hints, scans, exports, nearline query, and cheaper storage for colder KV.
In simple words
In one sentence: this page explains how we keep LLM context reliable in production. We store time, meaning, and trust signals so each request can use only the context that is still valid now.
What to remember
Context is more than a search result. It is timeline, freshness, permissions, and what already happened.
How to use it
Build your product flow first, then let MatrixArk assemble prompt-ready context, route fast paths, and keep stale context out.
What you get
Fewer wrong-time answers, better cost control, and cleaner reuse of stable prompt parts.
What we get from MatrixDB
- Redis-compatible adoption for strings, hashes, profiles, session state, and LLM integration metadata.
- Hot context metadata such as active summaries, cached retrieval results, LMCache metadata, eligibility keys, and invalidation hints.
- Infrastructure-agnostic APIs so applications keep familiar Redis semantics while MatrixDB handles placement, persistence, scaling, and cost underneath.
- Persisted KV that can support scans, exports, repair, analytics, and training joins.
- Tenant-aware placement, quotas, routing, and noisy-neighbor control.
- Lower cache cost by moving colder KV to cheaper disk-backed storage.
When to use it
Use MatrixDB when the value is mostly current state, not a time-ordered context timeline. If the question is "what happened and what should enter the prompt?", use TemporalStore. If the question is "what current profile, hash, metadata, or cached state should I fetch quickly or scan later?", MatrixDB is the right supporting store.
Other use cases, simply
MatrixDB can also serve leaderboards, catalogs, inventory, service flags, and general KV when eventual consistency is acceptable. These are useful secondary use cases; they should not replace the primary MatrixArk story around LLM context management and prompt engineering.