Enterprise storage backend Enterprise only
MatrixObject: shared-object storage for disaggregated Context serving.
MatrixObject is the flagship enterprise storage backend for TemporalStore. It separates compute from storage so many datanodes read and write the same durable blocks concurrently, with low-latency durable appends and elastic capacity — the foundation for large-scale, five-nines Context deployments.
Why it exists
When one disk per node stops scaling, disaggregate.
The open-source TemporalStore ships with local-disk and MatrixRaft backends. Both bind a shard to the node that owns its disk: durable data lives where compute lives. That is simple and fast until Context outgrows a single fleet — retention climbs into terabytes, ingest and retrieval want to fan out across many nodes at once, and every node failure means a full state transfer before the shard can serve again.
MatrixObject breaks that coupling. Durable state — blocks, bands, slabs, and replay history — moves into a shared object store, and datanodes become stateless for durable data. The consequences compound:
- Compute and storage scale independently. Add serving capacity for a traffic spike without moving data; grow retention without touching the serving fleet. Capacity is a storage decision, not a compute one.
- High-concurrency shared storage. Many readers and writers share one durable namespace, so concurrent Context ingest and retrieval spread across nodes instead of queuing behind per-node disk ownership.
- Durable low-latency writes. The WAL append path stays fast — MatrixObject avoids the per-write penalty of generic network file systems while data stays durable and replicated.
- Fast recovery and rebalance. When a datanode fails, its shards re-attach elsewhere simply by reopening blocks. No full state transfer, so recovery and elastic scale-out happen in seconds rather than hours.
Built for Context scale: high-cardinality agent memory, millions of Context nodes, replayable evidence, and mixed hot/cold access under sustained concurrent read/write.
Where it sits
The durable tier beneath the serving core.
Datanodes hold only hot working state; every durable block lands in MatrixObject, so any node can reopen any shard. That is what makes recovery and rebalance a metadata operation, not a data copy.
Selecting it
One backend setting on the datanode.
# Point the durable tier at MatrixObject (Enterprise)
TS_STORAGE_BACKEND=matrixobject
TS_MATRIXOBJECT_ENDPOINT=matrixobject://cluster-a/context
TS_MATRIXOBJECT_BAND_SIZE=64MiB # slab/band sizing for cold blocks
# Datanodes stay stateless for durable data; WAL still appends locally, then seals into shared blocks.The rest of TemporalStore is unchanged — the same shards, WAL, and data models serve on top; only where durable blocks live has moved.
When to use which backend
Pick the storage backend that fits the deployment.
| Backend | Best for | Consistency & scale |
|---|---|---|
| Local disk open source | Single-node, dev, edge, and self-hosted deployments. | One owner per shard; simplest operations. |
| MatrixRaft open source | Replicated high availability without shared storage. | Consensus-replicated WAL; fixed replica set. |
| MatrixObject Enterprise | Large-scale, disaggregated, concurrent read/write at five-nines. | Shared durable storage; compute scales independently. |
Enterprise storage family