Bespoke OLAP: Synthesizing Workload-Specific One-size-fits-one Database Engines

TL;DR

Bespoke OLAP is presented, a fully autonomous synthesis pipeline for constructing high-performance database engines tightly tailored to a given workload, and can generate a workload-specific engine from scratch within minutes to hours, achieving order-of-magnitude speedups over modern general-purpose systems such as DuckDB.

Abstract

Modern OLAP engines are designed to support arbitrary analytical workloads, but this generality incurs structural overhead, including runtime schema interpretation, indirection layers, and abstraction boundaries, even in highly optimized systems. An engine specialized to a fixed workload can eliminate these costs and exploit workload-specific data structures and execution algorithms for substantially higher performance. Historically, constructing such bespoke engines has been economically impractical due to the high manual engineering effort. Recent advances in LLM-based code synthesis challenge this tradeoff by enabling automated system generation. However, naively prompting an LLM to produce a database engine does not yield a correct or efficient design, as effective synthesis requires systematic performance feedback, structured refinement, and careful management of deep architectural interdependencies. We present Bespoke OLAP, a fully autonomous synthesis pipeline for constructing high-performance database engines tightly tailored to a given workload. Our approach integrates iterative performance evaluation and automated validation to guide synthesis from storage to query execution. We demonstrate that Bespoke OLAP can generate a workload-specific engine from scratch within minutes to hours, achieving order-of-magnitude speedups over modern general-purpose systems such as DuckDB.

Figures (8)

• Figure 1: Synthesized Bespoke engines exceed the performance of a decade of engineering, achieving 11.78$\times$ and 9.76$\times$ lower total runtime and 16.40$\times$ and 4.66$\times$ median per-query speedups on TPC-H and CEB, respectively, over DuckDB.
• Figure 2: Overview of the Bespoke OLAP idea: one engine is generated per workload (left), and the pipeline to synthesize one engine (right). The pipeline works as follows: Based on the DBMS Contract (SQL Query Templates ① and Dataset ②), the Bespoke Agent iteratively generates the query execution engine③, compiles, deploys④, and validates it⑤, and uses performance and correctness results to guide further code generation. At runtime, the generated bespoke engine exposes interfaces for ingest, for the query workload, and even ad-hoc queries, which are routed to a generic SQL processor ④.
• Figure 3: Steps to produce a Bespoke Engine. Each step is executed in loops, with validation to check whether the step's goal is achieved. ① will produce a storage plan for the specified workload. ② produces a functional engine based on the storage plan coupled with continuous validation and testing to steer the iterative coding process (see arrow below). The optimization loop produces an optimized engine iteratively by leveraging additional information such as actual summaries of the data ③, self-profiling ④, expert knowledge from the DBMS research literature⑤, and taking the perspective of expert database engineers ⑥.
• Figure 4: Overview of the infrastructure supporting LLM-driven OLAP engine synthesis. The Bespoke Agent first performs shared preparation and then branches into independent per-query optimization threads (①). Code modifications are applied through hotpatching (②), allowing incremental recompilation and replacement of individual components without restarting the running database process. Each change is automatically validated using fuzzy testing and benchmarking against DuckDB to ensure correctness and measure performance (③). All states are tracked using snapshot-based versioning with external regression monitoring (④), enabling rollback, reproducibility, and monotonic optimization. This infrastructure provides a fast, correct, and recoverable synthesis loop.
• Figure 5: Per-query runtimes for TPC-H (SF=20) and CEB (SF=2). Bespoke-TPCH/CEB outperforms DuckDB on every query.