The Business Case for AetheriusDB
This page is for the person deciding whether to adopt AetheriusDB, not the person already using it. It sets out where the advantages come from, what has actually been measured, and what the limits are.
Who gets the most out of AetheriusDB?
Section titled “Who gets the most out of AetheriusDB?”The value is different for a large organisation and for a small team, but both come from the same property: one engine covering ground that normally takes several.
| An enterprise platform team | A startup engineering team | |
|---|---|---|
| Main gain | Removes whole systems — and the sync pipelines between them — from the estate | Ships a full SQL + vector + graph + time-travel product without hiring for four datastores |
| Operational effect | One thing to deploy, monitor, back up, patch and capacity-plan instead of four | One binary on one machine; no orchestration layer to stand up on day one |
| Consistency | The same fact stops existing in four places with four freshness guarantees | No “the vector index is 20 minutes behind the database” class of bug |
| Governance | RBAC and row-level security compiled into the plan, applied to relational, vector and graph access alike | Security model is there from the start rather than retrofitted |
| Change management | Branch the database to rehearse a migration against real data | Same mechanism, without needing a staging estate to do it in |
| Auditability | Time-travel queries answer “what did this row say last quarter” without an audit table | Compliance answers available before compliance is a department |
For the workload-shaped version of this table — AI/RAG apps, real-time analytics, multi-tenant SaaS, edge fleets — see What is AetheriusDB?
How does one engine replace several databases?
Section titled “How does one engine replace several databases?”A typical modern data stack is a relational database for the system of record, a vector store for embeddings, a graph database for relationships, and an audit/temporal store for history. Each holds an overlapping copy of the same entities, and the copies are reconciled by pipelines.
AetheriusDB serves all four access patterns over the same tables:
| What you run today | What replaces it | How |
|---|---|---|
| Vector store alongside the database | TENSOR(n) columns with HNSW / IVFFLAT indexes | Embeddings live in the row they describe — vector search |
| Graph database for relationship queries | Graph index and link traversal | Relationships recorded once, navigated directly instead of re-joined per query |
| Audit tables, triggers, change-log | SQL:2011 system-versioned tables | SELECT … FOR SYSTEM_TIME AS OF — temporal tables |
| Scheduled jobs refreshing summary tables | Cascade tables that recompute themselves | Table types |
| App servers pulling rows to reshape them | WASM compute cells running next to the data | Only the result crosses the network |
| ETL keeping the copies consistent | — | There is one copy |
The compounding effect is the pipelines. Four systems means the data plumbing between them, plus the monitoring on that plumbing, plus the on-call rotation for it, plus the reconciliation work when it silently drifts. That work disappears when there is one copy of the data — and it disappears whether the team is fifty engineers or five.
A single query can filter relationally, rank by vector similarity, and traverse a relationship — with no synchronisation step in between and no question about which system is authoritative.
How fast is AetheriusDB?
Section titled “How fast is AetheriusDB?”The current reference measurement is a 31-query analytical suite over 10,068,831 rows of a star-shaped e-commerce schema, run on an Apple M4 (10 cores), 16 GB RAM, single client, warm cache. Full schema, every query’s SQL and per-query row counts: 10M-Row Query Benchmark.
| Queries completed | 30 of 31 (one self-join did not complete) |
| Total warm time | 23.7 s |
| Input rows processed | 138,488,310 |
| Aggregate throughput | 5.8 M rows/s |
| Scan-bound query band | 2–8 M rows/s — joins, grouped aggregates, window functions |
| Metadata-path queries | 0.1–0.3 ms against millions of logical rows |
| Correctness | All 30 completed queries checksum-identical to the recorded baseline |
Two results are worth reading closely, because they say where the engine’s character is:
- Some queries never touch the data. An integer range over a materialized month column answers in 0.1 ms; the same slice written as a timestamp range costs ~1,300 ms. That gap is cube-skip pruning working versus not working — a modelling decision with a four-order-of-magnitude consequence.
- Ingest is separately measured at roughly 180,000–330,000 rows/s for relational tables, depending on column count — see Benchmarks.
Why is it fast?
Section titled “Why is it fast?”Five mechanisms, none exotic on its own; the combination is the point. Note that the first two are opt-in and off by default — the benchmark run above does not record which flags were set, so treat these as capabilities to enable and measure, not as an explanation of those specific numbers.
- Whole-query JIT compilation — a query plan is compiled to native code
rather than walked by an interpreter, so the per-row cost is machine
instructions instead of dispatch. Opt-in:
enable_jit = true. JIT Compilation - Morsel-driven parallelism — work is split into cache-sized morsels
scheduled across cores, so a scan uses the whole machine without a
coordinator bottleneck. Opt-in:
enable_parallel = true. Morsel Parallelism - Skipping data instead of reading it — per-cube bounds let the planner discard whole regions of a table before any row is touched. This is why four queries in the suite return in a fraction of a millisecond. Advanced Indexing (PTI)
- Zero-copy, memory-mapped residency — columns are read directly out of the
mapping rather than parsed into row objects, and hot data stays resident while
cold data ages down automatically. You can override the policy with
PIN TABLE. Multi-Tier Residency · Pinned Tables - No write-ahead log to replay — durability comes from a checkpoint bit flip, so restart is not gated on log replay. Crash Recovery & Durability
Where do the cost savings come from?
Section titled “Where do the cost savings come from?”Three places, in descending order of how confidently they can be stated.
1. Fewer systems. This is the structural one, and it is the largest. Consolidating four datastores into one removes four sets of licences or managed service bills, four upgrade cycles, four monitoring surfaces, four backup regimes and the pipelines joining them — plus the engineering time that goes into all of it. That time is usually the bigger number.
2. Modest hardware for the data size. The 10-million-row benchmark above is not a cluster result. The entire dataset is 4.1 GB on disk, the engine accounts its encoded working set at 760.7 MB, and the whole 31-query suite runs inside roughly 3.3 GB of RAM on a 16 GB laptop with zero cubes spilled to disk. Ten million rows of a four-table star schema, answered analytically, on hardware a developer already owns. See the memory footprint breakdown.
3. Less data in flight. Sending logic to the data instead of rows to the application — a WASM compute cell returning a result rather than an app server fetching rows and discarding most of them — cuts network transfer and the app-tier capacity that exists purely to reshape query results.
Why is it a good choice for AI workloads?
Section titled “Why is it a good choice for AI workloads?”An AI application usually needs three things at once: a semantic search over embeddings, a hard relational filter, and context pulled from related entities. In a conventional stack those are three systems and two sync pipelines.
- Embeddings live in the row they describe. A
TENSOR(n)column sits beside theTEXT, thecustomer_idand the timestamp. The retrieval filter and the similarity ranking are the same query, so “top 10 similar documents that this tenant is allowed to see and were updated this month” is one statement, not a two-stage fetch-then-filter. Vector Search - No embedding-sync lag. There is no window during which the vector index disagrees with the system of record, because there is no second copy.
- Graph context without a second database. Retrieval-augmented pipelines that expand from a matched row to its neighbours use link traversal over the same tables.
- Feature transforms run in the database. Sandboxed WASM cells compute over a view of the data and return the result — no round-trip to a feature-engineering service.
- Reproducible training sets. Time-travel
means “the data exactly as it stood when we trained the model” is a
SELECTclause, which is also the answer to most model-audit questions. - Quality gates in the schema. AI quality constraints let the database reject malformed or out-of-distribution model output at write time.
Before designing around this: bulk embedding load is the weakest measured path in the engine — see the limits below.
enable_htap = true · mixed transactional + analytical load on the same table Serving live writes and analytical scans against the same table (HTAP) is implemented and enabled with a flag — relevant if the AI workload reads the same tables the application writes. See the configuration matrix.
What are the limits to factor into an evaluation?
Section titled “What are the limits to factor into an evaluation?”Adopt this page’s claims with these alongside them. None of them is hidden elsewhere in the docs; they are collected here because this is the page where they matter to a decision.
- Joins are the slowest query class, by roughly an order of magnitude against scans and aggregates. In the 10 M-row suite, four-table star joins run 1.0–2.0 s and one self-join did not complete at all. If your workload is join-dominated, benchmark it before committing.
- Vector ingest measured slow, and vector retrieval is unmeasured. A recorded
run loaded
TENSOR(32)rows at 46 rows/s. In that same run the HNSW index build failed, so its kNN timing describes a table with no working vector index and cannot be read as retrieval performance. This qualifies the “replaces your vector store” claim above: the structural case (embeddings in the row, no sync lag) holds, but bulk embedding load is measured slow and indexed kNN latency has not been established. See Benchmarks. - Every published figure is single-client. No concurrent-load or multi-user scaling measurement exists. Nothing on this page describes behaviour under production concurrency.
- No comparative or industry-standard benchmark has been run. No TPC-H, TPC-C, or ClickBench, and no published comparison against another engine.
- Warm-cache, fits-in-memory results. The 10 M-row suite ran with zero cubes spilled. Behaviour when the working set exceeds RAM is not characterised here.
- Not a drop-in PostgreSQL replacement. The pgwire endpoint covers a broad
ANSI SQL surface and many
psql/ JDBC / BI workflows run unchanged, but exotic extensions, system catalogs and procedural-language behaviour may differ. - Not a document database. Columns are rigidly typed at ingest; there is no schemaless JSON mode.
- Feature maturity varies. Several capabilities referenced above are opt-in or evolving. Check the availability badge on any feature page — and the configuration matrix — before depending on it.
How should we evaluate it?
Section titled “How should we evaluate it?”- Read What Makes AetheriusDB Different for the architectural claims in detail, including what it does not claim.
- Check the configuration matrix for which of the features you care about are on by default.
- Install it — single daemon, no orchestration — and run the Quickstart.
- Load a slice of your data and time your query shapes. Given the join caveat above and the absence of comparative benchmarks, your own workload is the only measurement that settles the question.