Bespoke OLAP: Synthesizing Workload-Specific, One-Size-Fits-One Database Engines

Authors: Johannes Wehrstein, Timo Eckmann, Matthias Jasny, Carsten Binnig (TU Darmstadt / Microsoft Gray-Systems-Lab / DFKI / hessian.AI) · Venue: PVLDB Vol. 19, No. 11, 2026 · arXiv: 2603.02001v2 (23 Jul 2026) · Code: DataManagementLab/BespokeOLAP

Databases OLAP LLM code synthesis Systems research C++

TL;DR

Headline Results

Total workload runtime (single-threaded)

Per-query speedups range from 2.83×–102× on TPC-H and 11.6×–1500× on CEB; Bespoke wins on every TPC-H query and loses on only two CEB queries versus Umbra (0.60× and 0.94×).

1  Why the Paper Matters

It is folk wisdom in the database community that “one size does not fit all” (Stonebraker & Çetintemel, 2005), yet even modern columnar engines like DuckDB and HyPer still support any schema and any valid SQL. That flexibility is not free: schemas are interpreted at runtime, tuple layouts stay generic, and operators are chosen for hypothetical rather than actual access patterns. Historically, building a workload-specific engine by hand cost the same as writing a new DBMS, so bespoke engines existed only for rare, high-value cases (e.g. TigerBeetle).

The paper’s central claim is that LLM-driven code synthesis has finally made bespoke engines economically viable — but only if the LLM is wrapped in a carefully engineered synthesis pipeline. Naive prompting fails because a DBMS is a system of deeply inter-dependent components (storage ↔ operators ↔ execution strategy), so uncoordinated edits either fail to compile, break correctness, or regress performance.

2  The Bespoke OLAP Pipeline

The system takes a DBMS contract — {query templates + parameter ranges, Parquet dataset} — and produces a stand-alone C++ engine tailored to that contract. Synthesis proceeds in strict stages, and correctness is never traded for performance.

Key design decisions

• Storage is planned once, then frozen. Any later change would invalidate all validated queries; the agent must commit to sort orders, encodings and auxiliary structures before writing any operator code.
• One conversation per query. The agent branches after storage planning; each SQL template gets its own independent per-query LLM conversation over a shared codebase, which localises complexity and prevents one query’s regression from polluting another’s history.
• Correctness first, performance second. A functional but slow engine is fully validated against DuckDB across many random parameter instantiations before optimisation even starts.
• No cost model — empirical join ordering. Rather than predicting the best plan, the agent measures alternatives on downscaled data during synthesis and hard-codes the winner (or emits multiple specialised implementations for distinct regions of the parameter space).
• Expert-knowledge file. A curated distillation of decades of DBMS research (sequential access, cache locality, SIMD, branchless code, inlining) is loaded into the agent’s context in Stage 5 so it can apply techniques selectively to traced hotspots.
• Ad-hoc / drift handling. Data is always materialisable to a flat relational format, so an out-of-contract query falls back to a generic SQL processor over the bespoke storage. Full workload drift ⇒ re-synthesise (cheap enough to be a nightly job).

3  The Supporting Infrastructure — “A System for System Generation”

Perhaps the most transferable contribution of the paper is not the pipeline itself but the infrastructure that makes tight iteration feasible for a full DBMS.

• Four agent tools only: compile, run/benchmark, shell, and a structured patch tool. The agent cannot touch the engine any other way.
• Live hotpatching & incremental compilation. The database process keeps running across thousands of edits; components are swapped in place, cutting validate-benchmark turnaround from minutes to seconds.
• Continuous fuzzy verification. Every candidate engine is compared against DuckDB on a diverse set of parameter instantiations — not one “golden” run — catching bugs that a single test case would miss.
• Snapshot versioning + automatic rollback. Every accepted change is a checkpoint; regressions are detected by an external monitor and reverted, guaranteeing monotonically improving engines.
• Supervisor agent. A second LLM watches the coding agent turn-by-turn, injects targeted corrections, and refuses to advance if a stage’s goal is not met — while staying stage-aware so it does not push premature optimisation.

4  Where the Speedup Actually Comes From

Ablation across stages (speedup vs DuckDB)

Every stage contributes measurably; the final “think like an expert DB engineer” pass is particularly potent because it re-examines whole functions rather than local hotspots.

Storage vs execution ablation

The takeaway: the generality tax lives beyond the operator layer. Even a compiled-query engine (Umbra) that eliminates interpretation overhead cannot match a system that also redesigns the physical layout around the workload. Storage and query specialisation multiply.

Concrete tricks the agent invented

• TPC-H Q1: partition lineitem into nine groups keyed by (returnflag, linestatus), each sorted by shipdate; replace scan with per-group binary search + pure sequential AVX-512 reduction (16 elements/cycle, two accumulators for ILP).
• TPC-H Q5: exploit orders sorted by orderdate; denormalise lineitem.supp_nationkey and pre-computed discounted_price next to orders.cust_nationkey; region/nation lookups become O(1) array indexing.
• TPC-H Q13: each orders row carries an alpha_mask (which letters occur in comment) and a bigram_mask that cheaply reject non-matching rows before any substring scan.
• Aggregate strategy usage across all queries: inline fused aggregation (97.4%), bitmap semi-joins (73.7%), dictionary predicate rewriting (71.1%), hash indices for O(1) joins (47.4%), pointer __restrict aliasing (50%).

5  Cost, Time, and Reproducibility

The authors also tried other frontier models (GPT-5.4-Codex, Claude Sonnet 4.7) with comparable speedups, and local open-weight models (Gemma-4, MiniMax-M2.7, GLM-4.7/5.1) which succeeded but required more retries. They interpret this as an instruction-following gap, not a fundamental limit of the approach.

6  How It Relates to Prior Work

7  Limitations & Future Work

• In-memory only. Buffer pool, eviction, and page layout synthesis are explicit next steps — early disk-resident results already work but speedups shrink.
• OLTP is open. Consistency and isolation add a whole new dimension the current pipeline does not address.
• Contract must be known in advance. Truly ad-hoc workloads fall back to a generic SQL processor over the bespoke storage — correct, but no specialisation benefit.
• Cost-model-free join ordering works empirically but might not scale to workloads with huge parameter spaces; the authors suggest lightweight learned cost models to prune synthesis choices.

8  Reviewer’s Take