Skip to content

Whole-Query JIT Compilation

QueryExecutionPerformance
Opt-in Implemented · off by default — enable with enable_jit = true

Most databases execute a query by walking an iterator tree: a Scan hands a row to a Filter, which hands it to a Project, which hands it to an Aggregate. Each handoff is a function call and every value is materialised in a generic, boxed form. That overhead dominates run time for analytical workloads.

When JIT compilation is enabled, AetheriusDB stops interpreting the plan and instead compiles a lowerable query into a single fused native kernel before it touches a row. Scans, predicates, expressions, and aggregates become straight-line code in one tight loop that streams directly from columnar memory into output — no per-row dispatch.

The fused kernel collapses what used to be hundreds of calls per row into a handful of SIMD-friendly instructions, and the compiler specialises the code for the actual shape of your data — a column that is almost never null gets its null-check branches removed entirely.

  • No interpreter tax — predicates and projections fuse into one loop.
  • Branch specialisation — rarely-taken branches (nulls, edge cases) are removed when statistics say they almost never fire.
  • Cache-resident execution — the compiled kernel and its working set stay in CPU cache, so the processor is fed at memory bandwidth.
flowchart LR
  classDef plan fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
  classDef fuse fill:#1f2640,stroke:#00d4ff,color:#e8eaf0
  classDef out  fill:#1f2640,stroke:#4ade80,color:#4ade80

  SQL[SQL text]:::plan --> AST[Logical plan]:::plan
  AST --> FUSE[Fused kernel<br/>Scan + Filter + Project + Aggregate]:::fuse
  FUSE --> ASM[Native machine code]:::fuse
  ASM --> ROW[Streamed result rows]:::out

Set enable_jit = true on the server. After that there is no per-query syntax — eligible queries compile automatically. You can inspect what was compiled with EXPLAIN (COMPILED).

-- A typical analytical query.
SELECT region, SUM(revenue) AS total
FROM orders
WHERE order_date >= '2026-01-01'
AND status = 'COMPLETED'
GROUP BY region;
-- Inspect what the engine compiled:
EXPLAIN (COMPILED) SELECT region, SUM(revenue)
FROM orders GROUP BY region;

The first run of a brand-new query shape pays a small compilation cost (single-digit milliseconds for typical queries). Later runs of the same shape hit a warm cache and skip compilation entirely.

Compiled kernels are keyed by query shape and reused across executions until invalidated. Two queries that differ only in literal values can share one compiled plan — if you parameterise them with bind placeholders rather than interpolating literals. With placeholders, a query you run thousands of times a second compiles once and reuses that plan; with inlined literals, each distinct literal compiles separately.