Redis-compatible migration
Redis-style commands and SDKs move profiles, hashes, strings, session state, context metadata, LMCache metadata, and KV with minimal app change while hiding the underlying serving, storage, and placement model.
MatrixDB
Supporting serverless KV for LLM context platforms.
TemporalStore can handle most LLM context serving by itself. Add MatrixDB when the platform needs database-specific KV features around that context: Redis-compatible access, multi-tenancy, online/offline/nearline KV, tens of millions of QPS, large summary and profile KV, active session summaries, cached retrieval results, TTL state, LMCache metadata, hashes, scans, exports, cheaper disk-backed capacity, and analytics-ready product data.
When to involve MatrixDB
MatrixDB is not the default starting point for LLM context management. TemporalStore is usually enough for serving memory, temporal KV, latest context values, replay, low-latency fetch, and prompt assembly. MatrixDB becomes valuable when the product needs a real KV database beside the context path: Redis-style access, large profile or summary records, online/offline/nearline access, tenant placement, scans, exports, cheaper storage, or analytics workflows. Applications keep a familiar Redis API surface while MatrixDB owns distributed placement, persistence, scaling, and operational visibility underneath.
Rule of thumb:
TemporalStore serves context: time-aware memory, temporal KV, latest KV, cache, and
persistence for request-time use. MatrixDB is the KV database when the workload needs
Redis-compatible access, multi-tenancy, tens of millions of QPS, large profile or summary
KV, scans, exports, offline/nearline query, and database-style operations.
Hot context state
Active sessions, current project summaries, user profiles, cache metadata, retrieval-result ids, and latest workspace state.
Redis-compatible adoption
Teams can migrate familiar cache/profile workloads while MatrixArk decides what should stay in TemporalStore versus MatrixDB.
LMCache bridge
Store prompt-section ids, cache eligibility, invalidation hints, source freshness, and reusable runtime-cache metadata.
Not broad analytics
Very flexible JSON scans, joins, group-bys, and schema discovery should route to OLAP/HSAP, then write summaries back when needed.
Product Advantages
Why MatrixDB as the supporting hot-state layer?
Extremely performant KV serving
Strings, hashes, profiles, and persisted KV scale through eventual consistency and optimized serving paths.
Multi-tenant control
Tenant and table isolation, quotas, routing, hot-key visibility, and placement policy help control noisy-neighbor risk.
Very large-scale storage
General KV, profiles, hashes, and offline-queryable data stay in MatrixDB, with colder KV kept on cheaper disk-backed storage instead of expensive memory-only cache.
System Architecture
Redis-compatible / SDK client
Tenant-aware proxy
Quota / router
Data node pool
Storage engine
Replication path
MatrixDB separates Redis-compatible client access, tenant-aware routing, elastic data placement, and persisted storage access. The proxy resolves tenant and table policy, applies capacity and isolation controls, routes requests to the right data nodes, and keeps profile, hash, string, large-scale KV, and offline query/export paths in a single eventually consistent KV database plane.
Serving Workflow
- Client issues Redis-style commands or SDK calls during migration or native MatrixDB adoption.
- Proxy resolves the tenant, table, quota, placement policy, route, and target data node.
- Data node executes the KV, string, or hash operation for the high-QPS online path.
- Offline or nearline query paths read persisted data for scans, exports, repair, analytics, or training joins.
- Operational metrics track online latency, query/export pressure, request mix, and storage health.
Scenario Architecture
Supporting hot state and nearline query beside TemporalStore.
Access
Applications use Redis-style clients, SDKs, or service-side proxies for online KV, string, hash, and profile workloads.
Route
The proxy and metadata layer apply tenant policy, quotas, and isolation before routing table and workload traffic to elastic data-node placement.
Operate
Shared MatrixArk monitoring tracks protocol traffic, tenant/table readiness, quota pressure, hot keys, data-node health, serving capacity, storage growth, and offline query/export load.
Capabilities
Scalable KV for context support, Redis migration, and query paths.
Redis out-of-the-box
Familiar Redis-style access for migration and LLM integrations while the backend handles distributed placement, persistence, tenant isolation, LMCache metadata, and operations.
LMCache metadata bridge
Store cache eligibility, reusable prompt-section ids, source freshness, invalidation hints, and runtime-cache coordination keys behind Redis-compatible APIs.
Multi-tenant profile serving
User, item, campaign, merchant, device, player, and game profiles through hash and KV access patterns across many teams and tenants.
Tenant isolation and quotas
Control tenant/table placement, capacity, hot-key pressure, request mix, and noisy-neighbor behavior from one serverless KV database plane.
Game leaderboards
Serve player scores, rank snapshots, season boards, guild state, and profile lookups with high-QPS reads, persisted storage, and Redis-compatible migration paths.
Offline and nearline query
Persisted KV state can be scanned, exported, repaired, or joined by offline jobs without treating the serving cache as disposable.
Cache plus cheaper storage
Useful when plain cache workloads need more capacity, persistence options, offline access, high QPS, and lower cost through disk-backed storage tiers.
Serverless scalable placement
Distributes online and persisted data across serving nodes so capacity can grow with tenants, tables, storage volume, and workload families.
LLM platform KV role
Serves Redis-compatible hot state with eventual consistency while TemporalStore handles temporal context and MatrixKV handles canonical truth that cannot be guessed from cache.
Operational UI
Shared monitoring and diagnostics with the rest of the MatrixArk platform.
Comparison
| Alternative | Good at | MatrixDB difference |
|---|---|---|
| Redis / Valkey | Fast single-node or clustered cache, mature ecosystem | Redis-compatible migration and integration path with serverless scale, tenant-aware placement, persistence, scans, exports, high-QPS serving, LMCache metadata, and very large-scale KV storage, not only cache capacity. |
| DynamoDB | Managed cloud KV and predictable operations | More control over Redis-compatible protocol choices, tenant-aware serving topology, high-QPS online paths, and product-specific KV access. |
| Bigtable / wide-column stores | Large sparse tables, scans, and ordered storage | MatrixDB focuses on high-performance KV/profile serving while keeping persisted data accessible for offline or nearline query paths. |
| TemporalStore | LLM context timelines, replay, memory deltas, counters, windows, and long sequences | MatrixDB is the eventually consistent KV database for supporting current-value state; TemporalStore remains the primary context engine. |
| Postgres / MySQL | Relational application data, joins, transactions, and familiar operational tooling | MatrixDB targets Redis-style hot KV/profile serving, tenant-aware placement, high-QPS access, cache-plus-storage, and scan/export paths rather than relational modeling. |
| ElastiCache / MemoryDB | Managed Redis-compatible caching and memory-first data structures | MatrixDB is positioned for larger persisted KV, cheaper disk-backed capacity, multi-tenant placement, scans, exports, and Redis migration beyond memory-only cache economics. |
Where MatrixDB fits
MatrixDB is the supporting Redis-compatible, multi-tenant KV database for the MatrixArk LLM platform when TemporalStore's serving scope is not enough: strings, hashes, large active session summaries, large profile and summary KV, context-pack metadata, LMCache metadata, cache eligibility keys, invalidation hints, entity attributes, service state, cache-plus-storage workloads, cheaper disk-backed storage for colder KV, tens of millions of QPS, persisted query/export paths, online/offline/nearline access, tenant-aware routing, isolation, quotas, elastic placement, noisy-neighbor control, and low-friction migration from existing Redis deployments.
Talk to MatrixArk