TTemporalStore.AI GitHub

Enterprise storage backend Enterprise only

MatrixKV: strongly consistent KV for critical platform state.

MatrixKV is the enterprise transactional KV foundation used alongside TemporalStore for routing metadata, shard placement, leases, timestamps, and ownership records — state where committed correctness matters more than cache-style freshness.

Why strong consistency

Control-plane state is small, but it must be exactly right.

A Context deployment keeps two very different kinds of state. There is the hot serving data — Context nodes, evidence, features — which is large and tolerates cache-style freshness. And there is the control plane: who owns which shard, where shards are placed, which epoch is current, what the routing table says. That state is tiny by comparison, but a single stale or reordered read of it can corrupt the whole cluster.

MatrixKV is the strong-consistency home for that second kind of state. Every read reflects the last committed write, and updates are transactional, so coordination decisions never race:

  • Leases & epochs. Protect primary ownership, drive controlled failover, and reject stale writers — a fenced writer cannot come back and overwrite newer data.
  • Routing & placement. Namespaces, shards, and placement records commit in a defined order, so every node agrees on where a shard lives.
  • Timestamps & schema. Table metadata and ordering points that the serving engines depend on stay transactionally correct.

Keeping this truth out of the hot serving path also makes failover, ownership, and routing far easier to reason about operationally.

TemporalStore control plane
Metaservershards & placement
Managerleases & failover
↓  reads/writes committed truth  ↓
Transactional state Enterprise only
MatrixKV — transactional KVleases · epochs · routing · ownership · timestamps

MatrixKV sits under the control plane, not the serving path — strong consistency where it counts, without slowing hot Context reads.

When to use which backend

MatrixKV is for truth, not hot serving.

Reach for MatrixKV when a wrong answer is worse than a slow one. For high-QPS hot state pick MatrixDB; for the durable blocks under disaggregated serving pick MatrixObject.

BackendBest forConsistency
Local disk / MatrixRaft
open source
Self-hosted single-node or replicated serving without a separate control-plane store.Per-shard or consensus-replicated.
MatrixKV EnterpriseMetadata, leases, ownership, routing, timestamps.Strong, transactional.
MatrixDB EnterpriseHigh-throughput KV serving and scans.Eventually consistent.
MatrixObject EnterpriseShared durable blocks for disaggregated serving.Durable shared storage.

Enterprise storage family

Explore the rest of the storage family.

EnterpriseMatrixObjectShared object store for disaggregated Context serving. EnterpriseMatrixDBEventually consistent high-throughput KV serving. ArchitectureTech & InfraHow the serving core, caches, and storage fit together.