Storage Lifecycle

StorageCold TierLifecycle

Beta Works · surface still evolving · cloud-tier transport is Beta; the local lifecycle is Stable

What it is

Traditional databases reclaim space with a reactive garbage-collection process — VACUUM, autovacuum daemons, periodic sweeps. These cause unpredictable I/O spikes, starve user queries of CPU, and occasionally fall behind so badly that disks fill up. AetheriusDB takes a different approach: space is reclaimed automatically and predictably — there is no vacuum daemon and no background sweep competing with your workload.

When operations like DROP TABLE, TRUNCATE, or an UPDATE retire a block of data that nothing needs anymore, the automatic lifecycle takes over: the block is streamed to cold object storage (S3, GCS, or equivalent) and its local storage is released. The data is never deleted — it is moved to a tier where it is dramatically cheaper to keep around forever, and it stays queryable through time travel.

Why it matters

The combined effect is predictable latency, effectively unlimited history, and no background daemon fighting your live workload for IOPS.

• No reactive vacuum, no I/O spikes — space is reclaimed as soon as data is no longer needed, not at some unpredictable later time.
• “Once in the database, always in the database” — old data tiers down to cheap storage where it stays addressable for time-travel queries.
• Efficient in a cluster — each retired block is uploaded to cold storage only once, minimizing egress cost.

flowchart LR
  classDef hot fill:#1f2640,stroke:#ef4444,color:#ef4444
  classDef cold fill:#1f2640,stroke:#7c5cff,color:#7c5cff
  classDef ok fill:#1f2640,stroke:#4ade80,color:#4ade80

  DDL[DROP / TRUNCATE / UPDATE<br/>retires old data]:::hot
  --> ENG[Automatic lifecycle<br/>tiers it out]:::hot
  --> COLD[Durable in cold<br/>object storage]:::cold

  COLD -. still queryable .-> OK[Time-travel query<br/>fetches from cold tier]:::ok

How you use it

The lifecycle is fully automatic. You write ordinary DDL and DML; the engine handles the rest. The only operator-facing surface is a few system queries you can use to observe what is happening.

-- Ordinary DROP. The data tiers out
-- to object storage in the background.
DROP TABLE archived_events;

-- An UPDATE creates a new version and retires the old one;
-- the old version tiers out once no transaction still needs it.
UPDATE accounts
   SET tier = 'GOLD'
 WHERE spend_last_year > 10000;

-- Time-travel query against data that may have already tiered out.
-- The planner transparently fetches from cold storage if needed.
SELECT *
FROM archived_events
FOR SYSTEM_TIME AS OF TIMESTAMP '2024-12-01 00:00:00';

-- Observe the residence tier of the data you care about.
SELECT table_name, residence_state, tiered_at
FROM system.storage_residence
WHERE residence_state <> 'HOT';

The residence view name above is illustrative; check your build for the exact system view. You never issue a “compact” or “vacuum” command. The cold fetch on a time-travel query adds a small first-byte latency, but the rows come back identical to a live read.

Maturity

The storage lifecycle is delivered in layers:

• Stable — the deterministic local lifecycle: local space is reclaimed as soon as data is no longer needed (never via a periodic sweep), DROP / TRUNCATE / UPDATE trigger it, and cleanup never fires while an active transaction still needs the data.
• Beta — the cloud-tier transport that ships retired data to S3/GCS, transparent time-travel fetch from cold storage, and orphan retry with backoff if cold storage is unreachable (no data loss). Use these in development and pilot environments.
• Roadmap — single-upload cold-tier writes in replicated clusters, cost-aware egress throttling, and per-table lifecycle health metrics.

Your SQL and DDL do not change between stages — only the operational characteristics (whether data is reclaimed locally or shipped to the cloud) and what you observe through the system views.

Key concepts

Concept	Meaning
Tiering out	Moving a block of data that nothing needs anymore to cold object storage.
In transit	The brief window between a block being retired locally and its cold-tier upload completing.
Residence state	A queryable column describing where each block of data currently lives.
Orphan safety	If cold storage is unreachable, the data stays on local storage — never lost.

Notes & caveats

Tip

Tables you actively pin in memory (for example, lookup dimensions) can be excluded from automatic tiering by configuration — pinned data never tiers out.

Heads up

Data stays available to every transaction that can still see it. Automatic tiering never fires while any active transaction can still read the data, which is what guarantees you never see “missing rows” mid-query. Very long transactions on shrinking tables can briefly delay reclamation.

Temporal Tables & Events →

Time-travel queries that transparently rehydrate cold data.

Spectral Foreign Keys →

How cold-tier parent data still keeps spectral children resolved.

Storage →

The full storage hierarchy from memory down to cold storage.