Query Data
AetheriusDB runs the same strictly-typed SQL surface everywhere, but how a query executes — and how fast — depends on a handful of engine features you can turn on and tune. This section explains each one: what it does for you, how to enable it, and the SQL you write to use it.
Each page carries an availability badge so you always know whether a feature is on by default, opt-in behind a flag, or still evolving. The configuration matrix is the source of truth for those defaults.
How fast is it
Section titled “How fast is it”Fast enough that things which are normally batch jobs become interactive:
- Relationship joins without scanning either table. A selective join along a declared relationship is answered as a direct lookup of the matching rows, so its cost tracks the number of rows matched rather than the size of the tables — unlike a query engine that rebuilds a hash table every time. This path has not yet been benchmarked with a committed harness; see Benchmarks for measured figures.
- Distinct counts and percentiles over billions of rows in milliseconds. “How many unique users this quarter?” over a billion events returns in sub-second time, with a bounded, reason-about-able error — or exactly, when you ask for exact.
- Queries run at native speed. A query can be compiled to one tight machine-code loop and spread across every CPU core, so you’re not paying interpreter overhead or leaving cores idle on a big scan.
You reach for these when a dashboard needs to feel instant, an API can’t wait on a multi-second query, or a nightly rollup is holding up the morning.
Why it’s better than a traditional database
Section titled “Why it’s better than a traditional database”Most databases treat every query as if it were the first one they’ve ever seen — re-planning it, rebuilding join structures from scratch, and scanning more than they need to. AetheriusDB is built to remember, approximate, and parallelize, while never giving up a correct answer to do it.
| You want to… | A typical database | AetheriusDB |
|---|---|---|
| Join related tables repeatedly | Rebuilds a hash table on every query | Remembers the relationship and hops straight to the matching rows — microseconds, no scan |
| Join on a composite / multi-tenant key | Match several columns by hand, every query | JoinKeys fold the columns into one token, so it’s a single-column fast-path |
| Count distinct / percentiles at scale | Full scan, seconds to minutes | Sub-second with bounded error — or exact on demand |
| Run one heavy query | Often one core, interpreted | Compiled to native code, fanned across all cores |
| Add graph or vector queries | Bolt on a second engine | Native in the same SQL you already write |
| Go faster | Risk stale or approximate results | Fast paths are correct by construction — if a shortcut can’t be proven fresh and safe, the engine silently falls back to the exact answer |
The last row is the one that matters most: you never trade correctness for speed. Every acceleration here is checked before it’s used, and declines to the ordinary, exact plan the moment it can’t guarantee the same result. Speed is opt-in and incremental — turn features on as you need them, tune them with flags, and keep the same strictly-typed SQL surface throughout.
The pages in this section
Section titled “The pages in this section”- Whole-query JIT compilation — compile a query into one native kernel instead of interpreting a plan tree. Opt-in.
- Morsel-driven parallelism — fan a single query across every CPU core. Opt-in.
- Adaptive query execution — switch strategy mid-flight when the data disagrees with the estimate.
- Advanced indexing (PTI) — an index that answers aggregates from its branch nodes and prunes whole subtrees.
- Graph index & navigational serve — turn a repeated relationship join into a microsecond lookup — no scan.
- JoinKeys — put multi-column and multi-tenant relationships on that same fast-path with one precomputed token.
- Approximate query processing — sub-second distinct counts, percentiles, and histograms with bounded error.
- Deep RL query optimizer — a planner that learns from real query latencies, with a deterministic fallback.
- Native multidimensional pivot — OLAP-style rotation, roll-up, drill-down, and write-back in SQL.
- Horizon materialization — declarative rules for which tier data lives in, plus predictive pre-building.