Storage Tiering Service · View 13 of 31 · 4 · Data
Decisions
- tenant_guard sits in the same Vitess shard as the tenant's placements. A commit reads guard_epoch and writes the placement in one single-shard transaction; no transaction ever spans tenants (ADR-21).
- Holds are scopes (workspace, folder, owner), not flags on nine billion rows. Placing a hold writes one scope row and bumps one epoch.
- Pack membership is a column of placement (pack_id, offset, length). A pack is not a container objects belong to; it is a location.
Sizing
- placement is under 400 bytes a row: about 3.7 TB for 9.2 billion objects, roughly 8 TB with secondary indexes, spread across 64 shards of 130 GB each.
- movement rows exist only while a movement is in flight or awaiting release, so the table stays in the low hundreds of millions of rows.
Key design
- Rows are sharded with a Vitess multicolumn vindex: a tenant hash prefix and an object hash suffix. A tenant with 400 million objects spreads across shards while single-tenant queries still route to a bounded subset.
