Skip to content

Storage & Durability

AetheriusDB keeps your hottest data in RAM and lets the rest age onto cheaper, durable media automatically — while guaranteeing that committed data survives a crash. This section covers the knobs you can turn and the guarantees you can rely on. You rarely need to touch any of them: the defaults are production-ready. Reach for these pages when you have a latency-critical table to keep in memory, a maintenance window to plan, or a durability question to answer.

You get in-memory speed on your hot data and cheap, durable capacity for the rest — without running a separate cache, a separate object-store loader, or a manual archival job. The engine tiers data automatically, and the defaults are production-ready, so “make it fast and keep it safe” is the out-of-the-box state, not a project.

  • No separate cache tier — the read/write cache is built in; there’s no Redis to deploy and keep coherent.
  • Automatic tiering — hot data stays in RAM, cold data ages onto cheaper media on its own; you steer it only when you want to.
  • Committed means durable — a crash never loses acknowledged data.
  • Hot reads are zero-copy from RAM. Warm data is kept in its native layout and read straight from memory — no deserialization step between storage and query.

  • Restart is an instant load, not a log replay. Recovery maps the durable image back in and resumes; there’s no replay pass to sit through, and a forced kill is safe too.

  • Multi-Tier Residency — how data moves between hot RAM, mapped NVMe, cold NVMe, and cloud archive, and how to steer it.

  • Pinned Tables — guarantee that a table (or a hot slice of one) never leaves memory.

  • Caching — the built-in read/write cache that keeps repeated reads in memory with no separate cache server to run.

  • Memory Compaction — automatic background reclamation that keeps memory tidy and queries fast.

  • Data Persistence Engine — durable, multi-database storage and the DDL that configures it.

  • Crash Recovery & Durability — what survives a power loss and how a restart brings the database back automatically.