Multi-Tier Residency
What it is
Section titled “What it is”AetheriusDB does not force the usual “is it on disk or in RAM?” binary. Every table’s data lives in one of several tiers: hot RAM where active data stays resident, memory-mapped NVMe for warm data, cold NVMe reached on demand, and an optional cloud archive for petabyte-scale history. The engine moves data between tiers based on how recently and how often it is touched.
This is transparent to your queries. The same SELECT works whether its data is
currently in RAM or sleeping in a cloud bucket — the engine pays the cost to
fetch what it needs and warms that data into a faster tier for the next caller.
Why it matters
Section titled “Why it matters”Two-tier systems force a choice: pay for enough RAM to hold the entire working set, or accept that anything outside RAM is slow. A tiered fabric lets the recent and the frequently-read data live close to the CPU while the rest stays on cheap durable media, with smooth, predictable transitions in between.
- Use the fastest tier that fits — hot keys hit RAM, long-tail history streams from NVMe or cloud.
- Cooperative prefetch — a query that spans tiers starts scanning the hot data immediately while colder data warms in the background.
- Capacity scales with budget — adding a deep tier expands your dataset without growing the RAM bill.
flowchart TB classDef hot fill:#1f2640,stroke:#00d4ff,color:#00d4ff,stroke-width:2px classDef warm fill:#1f2640,stroke:#7c5cff,color:#e8eaf0 classDef cold fill:#0d1322,stroke:#2a3354,color:#b1b7cf L1["Hot RAM<br/>active data, resident"]:::hot L2["Mapped NVMe<br/>warm, page-cache backed"]:::warm L3["Cold NVMe<br/>fetched on demand"]:::warm L4["Deep Archive<br/>object storage (S3 / GCS)"]:::cold L1 <--> L2 L2 <--> L3 L3 <--> L4
How you use it
Section titled “How you use it”The engine manages residency automatically based on access patterns. You can inspect and influence it: see where each piece of a table currently lives, pin specific tables for guaranteed hot residency, set how aggressively the deep archive is used, and warm a known-cold range before a report.
-- See which tier each part of a table currently resides on.SELECT table_name, segment_id, tier, last_accessed, velocity_score FROM aetherius_system.residency WHERE table_name = 'orders' ORDER BY velocity_score DESC;
-- Allow large historical tables to age into the deep archive.ALTER TABLE events_2024 SET tier_policy = 'auto_archive_after_90_days';
-- Hint the engine to prefetch a known-cold range before a report.WARM TABLE orders WHERE created_at >= '2026-01-01';After the WARM hint, the bytes are in mapped NVMe before the report query
fires, eliminating the first-query latency you would otherwise see for cold data.