The storage service
The storage service is the durable byte layer of a cell. It holds objects
and blocks, protects them with erasure coding, verifies them with integrity
sweeps, moves them between tiers, and replicates them to peer cells. It is the
foundation the data service's lakehouse and catalog sit on.
Feeds: Data Platform.
What it owns
- Object and block storage: the primary durable store for cell data.
- Erasure coding: the durability scheme that survives device and cell loss.
- Tiering: moving objects between performance and capacity tiers by policy.
- Integrity: durability sampling and verification, holding an unreadable object apart rather than serving it.
- Replication: cross-cell copy, repair, and relay, including the disconnected case.
Sub-modules (public names)
| Sub-module | What it does |
|---|---|
| Object & block engine | The core byte store for objects and blocks |
| Namespace & addressing | Namespaces, object addressing, and per-namespace policy |
| Placement | Where an object's shards land across devices and cells |
| Erasure coding & protection | Durability coding and the protection scheme |
| Integrity | Durability sampling; holds unreadable objects apart |
| Tiering | Policy-driven movement between storage tiers |
| Relocation | Moving data between placements and cells |
| Replication | Cross-cell copy, repair, and relay |
| Topology | The device and cell topology placement resolves against |
| Service groups | Erasure and replication groupings of cells |
APIs and surfaces
The storage service exposes an S3-compatible object API alongside a native
object surface, both served over its HTTP listeners: a loopback clear port for
intra-cell callers and a mutual-TLS port advertised on the fabric for
authorized peers. Its gRPC surface carries cross-cell replication and
repair (StorageReplication) under mutual TLS. External object clients reach the
S3 surface only through the node gateway; the storage listeners
themselves are for intra-cell and cell-to-cell traffic. See the
Ports & protocols reference.
Workers
Background workers run integrity sweeps (sampled, never a full sweep of every object per pass), tier transitions, erasure repair, and replication catch-up. Each runs per cell.
The data path
Figure: the storage data path. Integrity is drawn verified (green); an object that fails verification is held apart (amber) rather than served; cross-cell replication is outlined because it crosses the cell boundary under mutual TLS. Ceiling: integrity is sampled per pass, not a full sweep of every object each cycle.
Table equivalent
| Step | What happens | State |
|---|---|---|
| Write | Object arrives via S3 or native API | neutral |
| Erasure code + place | Shards coded and placed across devices/cells | neutral |
| Durable store | Object held durably | core |
| Integrity sweep | Sampled verification | verified |
| Fails verification | Object held apart, not served | refusal |
| Replication | Copied to peer cells over mutual TLS | edge (cross-cell) |
In the deployment matrix
storage runs identically everywhere. Single-cell, replication listeners are
present but idle and durability is local erasure coding. Multi-cell, service
groups define erasure and replication sets that can span zones, regions, and
clouds. Sovereign / air-gapped, replication to an unreachable peer is deferred
and relayed, the peer is modeled as absent, and the local store remains fully
serviceable.
Related topics
- Data Platform, the area storage underpins.
- Replication, DR & federation, replication scopes and DR.
- Data residency, residency pinned on a workspace or clean room.
- Ports & protocols reference.