Module bigtable 

BigTable backend for high-volume, low-latency storage of small objects.

Row Format

Each row key is the object’s storage path. A row contains either an object or a tombstone — never both. The two layouts are mutually exclusive and distinguished by column presence:

Column	Family	Content	Present when
p	fg/fm	Compressed payload bytes	Object row only
m	fg/fm	[Metadata] JSON	Object row only
r	fg/fm	Redirect path to LT storage	Tombstone row only

The r column signals a tombstone row: its value is the long-term ObjectId serialized via as_storage_path(). Callers can resolve the LT object directly from the r value without reconstructing it from the row key. Its column family and timestamp carry the tombstone’s concrete expiration deadline.

p/m and r are mutually exclusive. Every write begins with a DeleteFromRow mutation that clears all columns before writing the new cells, so mixed rows cannot exist.

Legacy Tombstone Format

Tombstones written before the r column layout used the object-row format with an empty p column and "is_redirect_tombstone": true in the m JSON. Both formats are supported for reading. A bigtable.legacy_tombstone_read metric is emitted on each legacy read. Legacy tombstones expire naturally by TTL/GC; a successful conditional expiry extension upgrades them to the r format. Tombstone metadata in the historical t column is ignored; the corresponding r cell contains all information needed by readers.

Structs

BigTableBackend

BigTable storage backend for high-volume, low-latency object storage.

BigTableConfig

Configuration for BigTableBackend.