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.
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.