What Makes AetheriusDB Different
This page collects the unique and differentiating features of AetheriusDB — the things it does that a conventional relational database does not. It is about architecture, not benchmarks; for measured performance see Benchmarks.
What makes AetheriusDB different from other databases?
Section titled “What makes AetheriusDB different from other databases?”The short answer: AetheriusDB collapses a multi-database stack into one engine, and lets your code run inside it.
| You want to… | A typical stack | AetheriusDB |
|---|---|---|
| Search text and vectors | Separate vector store, kept in sync | Native TENSOR(n) columns in the same table |
| Follow relationships | Rebuild a hash join every query | Hop directly along a declared link |
| Read historical state | Bolt on an audit table | Query the table AS OF a past time |
| Reshape data for an app | Pull rows to an app server | Run a WASM cell next to the data |
| Keep a summary current | Schedule a refresh job | A cascade table refreshes itself |
| Test a schema change | Restore a copy of the database | Branch the database |
Why is one engine for SQL, vectors, and graph better than separate systems?
Section titled “Why is one engine for SQL, vectors, and graph better than separate systems?”Most stacks bolt together a relational database, a vector store, a graph database, and a temporal or audit store. Each one holds a copy of overlapping data, and the copies must be kept in sync — a pipeline that can lag, drift, or fail silently.
AetheriusDB serves all four query styles over the same tables. A single query can filter relationally, rank by vector similarity, and traverse a relationship, without a synchronisation step between systems and without the consistency questions that come with holding the same fact in four places.
What is unique about running code inside AetheriusDB?
Section titled “What is unique about running code inside AetheriusDB?”AetheriusDB lets you deploy logic as a WASM compute cell that runs inside the database, next to the data. The cell receives a view of the data, computes, and returns only the final result.
The conventional alternative is an application server that pulls rows over the network, deserializes them, reshapes them, and discards most of what it fetched. Moving the code to the data instead of the data to the code turns many round-trips and serialization passes into a single call. Cells are sandboxed and cannot open files or make network calls.
What is unusual about how AetheriusDB handles joins?
Section titled “What is unusual about how AetheriusDB handles joins?”In a conventional database, a join between two tables is recomputed from scratch on every query — typically by building a hash table over one side and probing it with the other, no matter how many times you have asked the same question.
AetheriusDB can instead record a relationship once, as a graph index, and navigate directly from a row to its related rows. For the fixed foreign-key paths an application walks repeatedly, this replaces per-query join construction with direct navigation. See Graph Index.
What tables can AetheriusDB do that a normal database cannot?
Section titled “What tables can AetheriusDB do that a normal database cannot?”Two table types have no direct equivalent in a conventional SQL database:
- Cascade tables recompute themselves when their source tables change. A normal database needs a scheduled job or a trigger to keep a summary current.
- Pulse tables keep only the latest state, replacing their contents on each write rather than accumulating rows — an O(1) flush for current-value data.
AetheriusDB also has group tables (several physical tables queried as one) and materialized pivot tables. See Table Types.
What does database branching give me?
Section titled “What does database branching give me?”AetheriusDB supports branching the database the way you branch source code: create a branch, make schema or data changes on it, and keep the main branch untouched.
The conventional equivalent is restoring a full copy of the database into a separate environment — slow, storage-hungry, and usually stale by the time it is ready. Branching makes “try this migration against real data” a cheap operation. See Database Branching.
What is time-travel querying and why does it matter?
Section titled “What is time-travel querying and why does it matter?”AetheriusDB implements SQL:2011 system-versioned tables, so you can query any table as it existed at a past moment:
SELECT * FROM accounts FOR SYSTEM_TIME AS OF '2026-01-01 00:00:00';In a conventional database, answering “what did this row look like last Tuesday”
requires having planned for it in advance — an audit table, a trigger, or a
change-log — and gives no way to run an ordinary query against the past. Here it
is a clause on a normal SELECT. See
Temporal Tables.
How does AetheriusDB manage memory differently?
Section titled “How does AetheriusDB manage memory differently?”AetheriusDB treats storage as a set of residency tiers rather than a single disk,
moving cold data down and keeping hot data in memory automatically. You can
override the policy directly with PIN TABLE, including pinning only the rows
matching a predicate.
This gives explicit control over what stays in RAM — closer to a cache you can reason about than to a conventional buffer pool that evicts on its own terms. See Multi-Tier Residency and Pinned Tables.
What does AetheriusDB not claim to be better at?
Section titled “What does AetheriusDB not claim to be better at?”Being honest about the boundaries:
- AetheriusDB is not a drop-in PostgreSQL replacement. It speaks the PostgreSQL wire protocol so existing clients connect, but its SQL surface and behaviour differ.
- It is not a document database.
- Joins are currently its slowest measured query class — see Benchmarks. The architectural advantages described above are design properties, not measured wins over another engine.
- No comparative benchmark against another database has been run. There are no TPC-H, TPC-C, or ClickBench results.
- Feature maturity varies. Check the availability badge on any feature page before depending on it.