Skip to main content

Workspace storage

Provisioning gives every workspace a dedicated object-storage namespace of its own. Storage isolation is therefore structural: it is a separate namespace with its own policy and its own classification, not a key prefix inside a shared bucket that a misconfigured policy could expose.

A clean room inherits its host workspace's storage and applies the room's egress policy over anything leaving it.

What you get​

SurfaceWhat it does
Namespace tree and object browserBrowse the workspace's namespace hierarchy and inspect object detail
S3 access keysThe workspace's own credentials for its S3-compatible surface
Presigned URL handlingRequests are verified from any conforming SigV4 client, including expiry. Customers mint with their own tooling
Tiering and retention editorsPer-bucket lifecycle rules, bounded by the classification floor
Managed tablesIceberg and Delta tables in the workspace's own storage, with a create wizard
External tablesRegistered with schema inference, or mounted from an existing connection
SFTPFile access to the workspace through the node gateway

Classification is a property of the namespace with a database constraint behind it, enforced in the data path rather than checked by a service in front of it, and it defaults to internal. Objects are versioned on every write, with delete markers rather than destructive deletes.

Crossing a cell boundary is a request, not a reach​

This is the part worth understanding, because it is where most storage models get quietly permissive.

A workspace spans cells, but reaching bytes that live on another cell is not implicit. Two things are filed into a shared access-request inbox for approval rather than granted because the caller happened to be a member:

  • Cross-cell access requests, to read what another cell holds.
  • Replica requests, to have a copy placed closer.

Both are governed operations with a record, which means "who asked for a copy of this, and who approved it" is answerable afterward.

Relayed fetch is visible​

When a workspace reads bytes it cannot fetch directly, the cell resolves the peer through a reachability algebra (direct, relayed, pending, partitioned or denied) and may plan a relay with ticketed hops.

Relayed fetch progress is surfaced to the user. A reader can see that bytes are arriving via a relay hop rather than directly, instead of watching a spinner that hides it. That is a small decision with a large consequence: the disconnected and partitioned cases are made visible rather than disguised as slowness, so an operator learns about a degraded path from the interface rather than from a timeout.

An air-gapped peer, meanwhile, is modeled as an absent edge rather than a failed peer to retry, so a permanently disconnected site does not generate a permanent error condition.

The guarantees underneath​

Everything a workspace stores inherits the object plane's properties, which are covered in full under object storage:

  • Content-addressed deduplication with double-checked locking, so identical concurrent writes deduplicate rather than race.
  • Every read verifies twice, a CRC32 against the on-disk checksum and a SHA-256 of the final plaintext against the content address.
  • Erasure coding or replication, topology-selected, with a checkable durability claim reporting measured conformance over a sample rather than a stated target.
  • Encryption that can be made mandatory, where the block store refuses a plaintext write rather than warning and proceeding.
  • A classification floor on tiering, so secret and above are never moved automatically and an unrecognised label fails closed to no movement.