TemporalStore infrastructure
Storage modes for durable LLM context.
TemporalStore separates the serving compute from the storage substrate, so a context deployment can pick the right durability and read-scaling for prompt context, session replay, tool timelines, and memory deltas — without forcing every context table through one path. The application context API stays identical across every mode.
Context state changes at very different speeds. Some is fast-moving: tool calls, user turns, retrieval feedback, and memory deltas update constantly. Some is slow-moving: summaries and profile enrichments change far less often. And durable online context sits in the middle — session history, open commitments, and replay state need stronger persistence while still benefiting from shared storage and elastic serving compute.
The design point: disaggregate compute and storage, then choose a durability mode per
context table based on update frequency, durability expectations, read fanout, and
recovery needs. Applications never see the difference — they still address context by
namespace, table, and key, over the same
shard-partitioned engine, with the same typed writes and time-window reads.
Why separate compute from storage
When the same nodes own request execution, cache, replication, and durable storage,
everything is coupled: adding read QPS can force a re-shard, adding ingestion can pressure
replicas, and recovery competes with live traffic. TemporalStore treats compute as the hot
serving layer and shared storage as the durable substrate for the write-ahead log
(wal), checkpoints, and retained records. Compute scales for ingestion and
reads; storage scales for durability, retention, and replay.
Three storage modes, one context API
Local disk and MatrixRaft are open source; MatrixObject shared storage is the enterprise disaggregated tier.
A backend resolver picks the mode from configuration — disaggregated shared storage when available, otherwise a shared-storage directory, otherwise replicated Raft, otherwise local disk — without changing the context model.
Match the mode to the context workload
The same context table can pick a different durability profile than the one next to it.
| Mode | Best for this context | What compute / storage separation buys |
|---|---|---|
| Async shared store | Fast-moving context: tool events, user turns, retrieval feedback, freshness counters, and long behavior sequences with extreme ingestion. | Compute absorbs writes and flushes to shared storage asynchronously; replicas scale read fanout while the wal handles replay and recovery. |
| MatrixRaft | Slow-moving context: batch-materialized summaries, profile enrichments, and table metadata refreshed by periodic jobs. | A replicated primary path protects important, less-frequently updated context without making every workload pay for it. |
| Sync shared store Enterprise | Durable online context: session memory, open commitments, policy counters, and recent profile deltas that need persist-before-acknowledge. | Persist to disaggregated shared storage before acknowledging, while read capacity and durable retention still scale independently. |
For the fast-moving path, the serving worker accepts the update, applies it to the
model-aware online state, serves hot reads, and persists the wal and retained
records asynchronously — so the hot write path never waits on a remote storage
round-trip. For durable online context, the sync path holds the acknowledgement until the
required record state is persisted, trading a little write latency for a clearer recovery
point. The tradeoff to publish in every mode is freshness: expose replica lag, checkpoint
progress, and time-to-visible as product signals.
How to choose
- Use async shared store when ingestion and read QPS dominate, context updates constantly, and every replica should serve reads.
- Use MatrixRaft when context is updated less often and the primary needs a clear replicated fault-tolerance path.
- Use sync shared store when writes need a stronger durable acknowledgement but the workload still benefits from compute / storage disaggregation.
- Keep the choice at the table level, so one context deployment can serve fast-moving, slow-moving, and durable-online context together.
The whole point is that durability is a deployment decision, not an application rewrite. The open-source engine and the resolver that picks these modes live at temporalstore.ai; the disaggregated MatrixObject shared-storage tier is the enterprise backend for durable context at scale.