KV Stores
MatrixDB and MatrixKV are supporting KV engines behind the MatrixArk platform.
Customers should integrate with MatrixArk for LLM context management and prompt engineering, not manually choose infrastructure products up front. The portfolio can use TemporalStore for most context serving, MatrixDB for Redis-compatible online/offline/nearline database KV, and MatrixKV only when low-volume transactional KV or strongly consistent data is required.
The simple split
| Engine | Use it for | What you get |
|---|---|---|
| TemporalStore | LLM context, prompt memory, replay, timelines, freshness, counters, long sequences. | Time-aware context assembled at request time. Good enough for most use cases. |
| MatrixDB | Hot profiles, session summaries, Redis-style hashes, cached retrieval metadata, LMCache metadata, TTL state, scans, exports, nearline query. | Eventually consistent serverless KV with familiar APIs, larger storage, lower cache cost, and hidden infrastructure complexity. |
| MatrixKV | Low-volume but high-importance permissions, document versions, approvals, leases, ownership, routing metadata, workflow checkpoints, and committed actions. | Strongly consistent transactional KV for records that must have one committed answer. |
Where MatrixDB fits behind the API
MatrixDB is the supporting KV store for current state around the context platform. It is useful when teams already have Redis-style access patterns, need hot reads, need LMCache or runtime-cache metadata integration, and also want persistence, scans, exports, tenant isolation, and cheaper storage for colder KV.
- Redis-compatible migration for strings, hashes, TTL state, and profile records.
- Redis-compatible integration APIs for LMCache metadata, cache eligibility keys, reusable prompt-section ids, and invalidation hints.
- Hot context metadata such as active summaries, cached retrieval results, and ranked context candidates.
- Infrastructure-agnostic client behavior while MatrixDB handles placement, persistence, scaling, and cost underneath.
- Nearline query paths for scans, exports, repair, analytics, and training joins.
- Tenant-aware routing, quota, placement, and noisy-neighbor control.
Where MatrixKV fits behind the API
MatrixKV is usually not required for context management. It is the supporting transactional KV store for the small, low-volume set of records where stale reads or conflicting writes can make an agent, workflow, route, metadata path, or rollout unsafe.
- Committed permissions, document versions, approvals, and workflow checkpoints.
- Ownership, leases, timestamps, routing metadata, and stale-writer fencing.
- Idempotency records and committed tool actions that must not apply twice.
- One accepted version of rollout, table, partition, object, or workflow state.
Other use cases, kept simple
MatrixDB and MatrixKV can support broader online-state systems, but those should not distract from the primary positioning around LLM context management and prompt engineering.
MatrixDB
Leaderboards, catalogs, inventory, profiles, service flags, and Redis migration when eventual consistency is acceptable.
MatrixKV
Low-volume strong-consistency state: object metadata, route ownership, table state, rollout state, idempotency, and committed workflow transitions.
Practical recommendation
- Expose one MatrixArk context and prompt-engineering surface to application teams.
- Route time-aware memory, prompt replay, counters, and long sequences to TemporalStore.
- Route hot current-value KV, Redis migration, scans, exports, and nearline query to MatrixDB.
- Route low-volume strongly consistent ownership, permissions, leases, and committed workflow truth to MatrixKV only when needed.
- Keep feature serving and general KV use cases secondary unless they directly support the context platform.