AetheriusDB Benchmarks

ReferencePerformanceBenchmarks

Every number on this page comes from a recorded benchmark run committed to the AetheriusDB repository, and each is labelled with the date of the run that produced it. Results that are unflattering are included alongside the good ones. Where AetheriusDB has not been measured, this page says so rather than estimating.

Read the caveats before quoting these numbers

These are results from specific runs on unrecorded hardware, not certified benchmark scores. See How should I interpret these numbers? below.

How fast is AetheriusDB?

On a recorded run from 2026-05-15, AetheriusDB ingested at roughly 190,000–330,000 rows per second depending on table width, and answered aggregate queries over a 500,000-row table in tens of milliseconds.

Concretely, from that run: a full COUNT over 500,000 rows took 72 ms, a five-bucket GROUP BY took 137 ms, and a 20-bucket GROUP BY over a 20,000-row table took 7 ms. Joins were the slowest category — a two-table INNER JOIN with a GROUP BY took 766 ms. The full 16-query suite completed with no errors in a 3.2-second total wall-clock.

What is the ingest throughput of AetheriusDB?

Measured ingest throughput, run of 2026-05-15:

Table	Rows	Columns	Insert time	Throughput
perf_users	20,000	5	60.8 ms	328,871 rows/s
perf_events	500,000	9	2.673 s	187,051 rows/s
perf_orders	200,000	8	615.1 ms	325,138 rows/s

Throughput tracks column count: the nine-column table ingested at roughly half the rate of the five-column one. A separate run on 2026-05-16 measured 180,648 rows/s loading 155,000 rows into standard relational tables, consistent with these figures.

What are AetheriusDB’s query latencies?

Selected query timings from the 2026-05-15 run, over a 500,000-row events table joined against a 20,000-row users table:

Query	Time
GROUP BY tier × region, 20 buckets (20 K rows)	7.0 ms
Full COUNT — 200 K rows	28.8 ms
Multi-condition WHERE, 3 predicates	59.8 ms
Scalar subquery — orders above average price	60.1 ms
Full COUNT — 500 K rows	72.0 ms
Filtered COUNT on a boolean	76.6 ms
ORDER BY DESC LIMIT 10	104.3 ms
GROUP BY region — 5 buckets, count + avg	137.2 ms
GROUP BY category × region — 30 buckets	183.4 ms
3-table JOIN — tier + category	262.6 ms
Conditional aggregation, CASE WHEN	384.4 ms
JOIN + multi-aggregate per region	732.5 ms
INNER JOIN events × users, GROUP BY tier	765.8 ms

Scans, filters, and aggregates land in the tens of milliseconds. Joins are currently the slowest operation class by roughly an order of magnitude.

How fast is AetheriusDB across different table types?

From the all-table-types run of 2026-05-16 (release build, seed 42, 183,000 rows total, 109.9 s wall-clock):

Table type	Rows loaded	Load time	Throughput
Group table	10,000	0.04 s	277,796 rows/s
Standard relational	155,000	0.86 s	180,648 rows/s
Property graph	1,000	0.02 s	43,491 rows/s
Cascade table	10,000	0.34 s	29,194 rows/s
Pivot table	2,000	0.19 s	10,617 rows/s
Pulse table	1,000	17.01 s	59 rows/s
Time travel (beacons)	1,000	20.50 s	49 rows/s
Vector / TENSOR(32)	2,000	43.28 s	46 rows/s

Read that table carefully: write throughput varies by more than three orders of magnitude across table types. Group and standard relational tables ingest fast. Vector, Pulse, and time-travel writes are, in this run, very slow.

Where is AetheriusDB currently slow?

Three areas measured poorly and are worth knowing about before you design around them:

• Vector ingest — loading 2,000 TENSOR(32) rows took 43.28 s (46 rows/s) on 2026-05-16. Vector queries in the same run were fast (kNN top-5 in 39.8 ms), so the cost is in the write path, not retrieval.
• Joins — the slowest query class in the 2026-05-15 suite at 766 ms, and a single JOIN … LIMIT 100 took 1910.7 ms in the 2026-05-16 run.
• Pulse and time-travel writes — 59 and 49 rows/s respectively on 2026-05-16.

What has AetheriusDB not been benchmarked on?

No standard industry benchmark has been run against AetheriusDB. There are no TPC-H, TPC-C, or ClickBench results, and no published comparison against another database engine.

Benchmark harnesses exist in the repository for graph traversal, RDMA latency, parser throughput, RL-optimizer gain, and several other subsystems, but they have no recorded results committed, so no numbers for those areas are published here. Concurrency and multi-client scaling have also not been measured — every figure on this page comes from a single-client run.

How should I interpret these numbers?

Six caveats apply to everything above:

1. Hardware is not recorded. The benchmark reports do not capture CPU, RAM, or storage device, so these results cannot be reproduced exactly or compared against another system’s numbers.
2. These are single runs, not averaged series. No variance or confidence interval is available.
3. Dataset sizes are modest — the largest table measured is 500,000 rows. Nothing here demonstrates behaviour at 100 M rows or above.
4. Single-client only. No concurrent-load or multi-user measurement exists.
5. In the 2026-05-16 run the HNSW index build failed with a parse error, so the vector-section figures reflect a table without a functioning vector index.
6. The Pulse-table section of that run recorded a row-count anomaly (1 row after inserting 500), so its 59 rows/s figure may be measuring something other than a healthy write path.

Where do these benchmark numbers come from?

All results on this page are reproducible from files committed to the AetheriusDB repository under black-box-testing/reports/:

• perf_benchmark_20260515_221151.{json,md} — ingest throughput and the 16-query latency suite.
• bm_all_types_20260516_185734.{json,md} — the all-table-types run.

The JSON files carry full float precision and per-query first-row values. If you need to verify or re-run these figures, start there.

JIT Compilation →

How AetheriusDB compiles hot query plans to native code.

Morsel Parallelism →

The parallel execution model behind these query times.

Advanced Indexing (PTI) →

Answering grouped aggregates without a table scan.

Index Types →

Choosing the index that fits your query pattern.