How AetheriusDB works
The one idea everything follows from
Section titled “The one idea everything follows from”Most databases treat memory as a storage area: rows are parsed into objects, copied between buffers, locked while in use, and written back out. AetheriusDB treats memory as a compute fabric: data is laid out once, in a form the CPU can work on directly, and queries travel to the data rather than copying data to the query. Almost every behavior below is a consequence of that single choice.
Data is stored as immutable blocks
Section titled “Data is stored as immutable blocks”Tables are kept as self-contained, immutable blocks of data. Once a block is finalized it never changes in place — an update writes a new block and the old one is retired. This is why so much of the system is simple and safe:
- Reads never contend with writes for the same data, so readers don’t block.
- Any past block can still be read, which is what makes time-travel possible.
- Copying or snapshotting is cheap, because finalized blocks never mutate.
See Storage & Durability for the user-facing knobs (tiering, pinning, caching) over these blocks.
Durability without a write-ahead log
Section titled “Durability without a write-ahead log”Traditional databases guarantee durability by first writing every change to a write-ahead log, then applying it, then replaying the log after a crash. AetheriusDB takes a simpler path: a block is built completely before it is made visible, and only then is it marked committed. Recovery after a power loss is therefore just “keep every block that was marked committed, discard anything that wasn’t.” There is no log to replay, which is why a restart is fast and needs no manual intervention.
See Crash Recovery & Durability for what this guarantees in practice.
Memory is a hierarchy, not a single tier
Section titled “Memory is a hierarchy, not a single tier”AetheriusDB treats fast memory as the top of a hierarchy and lets data age downward as it cools: the hottest data stays in RAM, warm data sits on local fast storage, and cold data can move to cloud archive — all while staying queryable. You can steer this with residency policies, or pin a latency-critical table so it never leaves memory.
See Multi-Tier Residency and Pinned Tables.
Columnar layout is why scans are fast
Section titled “Columnar layout is why scans are fast”Within each block, values for a column are stored together rather than row by row. Analytical queries that touch a few columns over many rows read only the columns they need, in long contiguous runs the CPU can process efficiently. This is the foundation the optional query accelerators (compilation, parallelism) build on.
See Query Data.
History is part of the data, not a side log
Section titled “History is part of the data, not a side log”Because finalized blocks are never overwritten, the database keeps an addressable history of committed states. That history is what powers querying a table as of an earlier moment and rewinding a running application to debug it — these aren’t bolt-on audit features, they fall out of how data is stored.
See Temporal Tables & Events and the Chrono Replay Debugger.
Relationships are followed as direct links
Section titled “Relationships are followed as direct links”A traditional join rebuilds relationships at query time, often by constructing a lookup table on the fly. AetheriusDB can instead follow a relationship as a direct hop from one related row to another, so graph-style traversals stay fast as data grows — without a separate graph database.
Logic travels to the data
Section titled “Logic travels to the data”Rather than pulling rows out to an application server, you can deploy a small sandboxed module — a compute cell — that runs next to the data and returns only the final result. Moving the logic to the data, instead of the data to the logic, removes round-trips and intermediate copies.
See In-Database Compute.
One engine behind several front doors
Section titled “One engine behind several front doors”The same engine and the same stored data are reachable over a native protocol, the PostgreSQL wire protocol, and Arrow Flight SQL at the same time. The protocol you pick is a matter of which ecosystem you’re in — they all execute against the same tables.
See Connect a Client and Wire Protocols.