GenDB: The Next Generation of Query Processing -- Synthesized, Not Engineered

AI summary

Overview

Research area: Database systems and query processing, specifically LLM-powered code generation for query execution. Technical level: Intermediate (readers should know basic database concepts such as OLAP, indexes, joins, and aggregation, but the paper's core argument is accessible without deep systems expertise). Scope: The paper argues that large language models should synthesize per-query execution code instead of engineers building and maintaining general-purpose query engines, and it presents an early prototype (GenDB) evaluated on OLAP workloads against five established engines.

What This Paper Is About

Traditional database engines are large, carefully engineered systems that are expensive to build, hard to extend, and slow to absorb new techniques and user requirements. The authors propose that an LLM-powered agentic system can instead generate customized, instance-optimized execution code for each incoming query, tailored to the specific data, workload, and hardware. GenDB is the proof-of-concept prototype, and the paper measures whether its synthesized code can beat state-of-the-art query engines on OLAP benchmarks.

Key Contributions

1. A new framing of query processing: the paper argues that LLMs enable a shift from continuously engineering and extending general-purpose engines to generating query-specific execution code, with the generated code amortized over repeated executions.
2. The GenDB architecture: a multi-agent system with dedicated agents for workload analysis, storage/index design, query planning, code generation, and query optimization, all operating with tool use (file operations, terminal access, web search/retrieval) and iterative runtime feedback.
3. An early prototype and empirical evaluation: implemented in JavaScript around Claude Agent with Claude Sonnet 4.6 as the underlying LLM, generating C++ execution code, evaluated on TPC-H at scale factor 10 and on a newly constructed benchmark, SEC-EDGAR, against DuckDB, Umbra, MonetDB, ClickHouse, and PostgreSQL.
4. A research agenda: a discussion of open challenges in reducing generation cost, improving robustness of generated code, and extending generation to semantic query processing and modern hardware such as GPUs.

Main Findings

• GenDB outperformed all baselines on every query in both benchmarks. On TPC-H (five representative queries), GenDB achieved a total execution time of 214 ms, reported as 2.8x faster than DuckDB (594 ms) and Umbra (590 ms), the two fastest baselines, and 11.2x faster than ClickHouse.
• Gains held on an unseen benchmark. On SEC-EDGAR, GenDB achieved 328 ms, reported as 5.0x faster than DuckDB and 3.9x faster than Umbra.
• The gap widened with query complexity. On TPC-H Q9, described as a five-way join with a LIKE filter, GenDB completed in 38 ms, reported as 6.1x faster than DuckDB.
• Iterative optimization produced large per-query improvements. TPC-H Q6 reached 17 ms at iteration 0 with zone-map pruning and a branchless scan and needed no further optimization. TPC-H Q18 started at 12,147 ms and dropped to 74 ms by iteration 1, a 163x improvement, attributed to replacing a cache-thrashing hash aggregation with an index-aware sequential scan. On SEC-EDGAR, Q4 fell from 1,410 ms to 106 ms over three iterations (13.3x), and Q6 fell from 1,121 ms to 88 ms over four iterations (12.7x); in Q6 the optimizer fused scan, compact, and merge operations into a single OpenMP parallel region, removing three thread-spawn overheads. By iteration 1, GenDB already outperformed all baselines.
• Four categories of optimization explain the gains: data-aware column encoding, algorithm-level restructuring (generating algorithms rather than selecting from fixed operators), cache-adaptive aggregation, and workload-specific derived data structures such as nibble-packed lookup files and batched-prefetch probe patterns.
• Aggregation code was adapted to group cardinality and cache capacity. TPC-H Q1 groups by returnflag × linestatus, producing 6 groups; with 6 fields per accumulator padded to a 64-byte cache line, that is 6 × 64 = 384 bytes per thread, which fits entirely in the 32 KB L1, so GenDB skipped hashing and used a direct array. TPC-H Q3 groups by order key with up to 4M distinct groups; 64 per-thread 4M-entry hash tables would total 64 × 4M × 12 B ≈ 3 GB, far exceeding the 44 MB L3, so GenDB used a single shared hash table with column-separated layout (keys 4M × 4B = 16 MB, values 4M × 8B = 32 MB), with probes touching only the key array and lock-free compare-and-swap updates to the value array.
• The multi-agent decomposition helped most on unseen workloads. On TPC-H, the multi-agent design achieved 236 ms versus 281 ms for the best single-agent variant (guided), a 1.2x difference; on SEC-EDGAR the gap widened to 2.3x over guided (752 ms) and 4.1x over high-level (1,325 ms). Removing domain-specific hints (guided to high-level) caused a 1.8x slowdown on SEC-EDGAR.
• The multi-agent design also cost less. $14.15 versus $17.54 on TPC-H and $23.49 versus $27.46 on SEC-EDGAR.
• The system is not fully robust. The authors report silent failures including non-terminating probe loops from incorrect open-addressing hash tables (notably on high-cardinality joins such as TPC-H Q18), agents hanging when token counts exceed the LLM output limit, and inter-agent misalignment such as downstream agents omitting a required DECIMAL scale-factor division. Current mitigations are a 300-second query-level timeout and a 30-minute agent-level timeout, with rollback to the best previous implementation.

Methodology in Plain English

The researchers built a system that treats each query as a small software project rather than a request handed to a fixed engine. GenDB takes as input the schema, SQL queries or natural language questions, the data, user settings (such as optimization targets and budgets), and available resources (hardware, or access to remote LLM APIs). A workload analyzer first inspects the hardware, schema, queries, and data to produce structured characteristics such as table and column statistics, join patterns, and filter selectivity. A storage/index designer then generates code that transforms the raw data into optimized layouts (for example columnar storage with encoding and compression) and builds indexes. A planner produces a resource-aware execution plan, and a code generator implements it in an appropriate language (C++ for high performance, Python for AI operations) with system-level optimizations. The generated code is then run to measure correctness and speed, and an optimizer uses that feedback to refine both the plan and the code iteratively until the user-configured budget or target is reached. Correctness is validated by comparing results against a traditional database system; where ground truth is unavailable, the authors recommend human expert inspection, and they note that natural-language-interface users receive no formal correctness guarantees, consistent with deployed conversational analytics services.

The evaluation compared against DuckDB v1.4.4, ClickHouse v26.2.1, Umbra (February 2026 release), MonetDB v11.55.1, and PostgreSQL v18.2 on an Ubuntu server with two Intel Xeon Gold 5218 CPUs (2.3GHz with 32 physical cores) and 384 GB RAM, with the whole database cached in memory and hot-run execution times reported. GenDB required no manual tuning of system parameters or indexes. To ensure fairness, the authors report two versions: one where each system uses only its automatically created indexes, and one where those are supplemented with additional indexes generated by GenDB. They used TPC-H at scale factor 10, selecting a representative subset (Q1, Q3, Q6, Q9, Q18) following prior work on representative TPC-H subsets, and introduced SEC-EDGAR, built from a real-world financial statement dataset (2022 to 2024, 5 GB, from the U.S. Securities and Exchange Commission) that has rarely been used for database benchmarking, to reduce potential data leakage from LLM training data. From SEC-EDGAR they generated 1,000 random queries using SQLSmith and applied diversity-based sampling to select six queries. An ablation study simplified the multi-agent pipeline into a guided single-agent variant and then a high-level single-agent variant with no domain hints.

Why This Matters

The paper challenges the assumption that high-performance query processing must come from large, general-purpose engines maintained over years. It suggests a different economics: generate code once for a query, then amortize the generation cost over repeated executions. The paper notes this is a realistic pattern — citing prior work that in 50% of Amazon Redshift clusters, 80% of queries exactly repeat previously observed queries, and that long-running analytical queries almost always recur.

Real-world applications:

• Recurring analytical and transformation workloads, where the upfront generation cost is amortized over many executions — the workload type the paper says GenDB is best suited for.
• Ad-hoc query environments, where GenDB could be combined with a traditional DBMS in a hybrid architecture: the traditional system handles one-off queries while GenDB accelerates frequent ones.
• Natural language analytics, by extending GenDB with a conversational interface for users without SQL backgrounds, while accepting the same lack of formal correctness guarantees as deployed conversational services.
• Semantic query processing over multimodal data, where an extended relational model lets a cell hold images or audio and generated code calls ML models or remote LLMs, shifting optimization toward inference cost and result quality.
• Modern hardware such as GPUs, through generated GPU-native analytical code using libraries such as libcudf for relational operators and RMM for memory management.

Industry relevance: For vendors and users of database systems, the paper points at a possible route around extension bottlenecks — where adding capabilities to systems such as PostgreSQL requires external extensions or purpose-built engines, and where extending existing systems is difficult and can introduce incompatibility and failures. It also implies a different skill profile: developers can inspect generated code for correctness, and verification is described as generally easier than implementing high-performance code or manually tuning query engines.

Future Directions

• Reducing generation cost by assigning models of different capability across pipeline steps (smaller models for simpler steps such as analysis, larger models for code generation) and across queries of different complexity; by generating reusable operators, data structures, and query templates rather than independent per-query code; and by reducing token consumption through more concise prompts, lower reasoning effort, and compression of inter-agent communication, schemas, and queries — while balancing that against generation quality.
• Improving robustness by integrating an external knowledge base for proprietary or unpublished optimization knowledge, systematically detecting silent failures such as non-terminating generated code and agents that hang past the output token limit, evaluating additional inter-agent protocols (TOON, MCP, A2A) beyond JSON and Markdown templates, and strengthening verification through formal verification for templated patterns and finer-grained feedback such as per-operator profiling or hardware counter analysis.
• Building a self-evolving system that maintains a persistent "experience" module, summarizing techniques that improved performance and issues that caused incorrect results, and folding validated rules back into prompts or system design.
• Extending flexibility to semantic query processing with ML models and remote LLM calls (including prompt tuning and model selection), and to GPU-native code generation leveraging libraries such as libcudf and RMM.
• Broadening the optimization objective from a single metric such as hot run time to constrained optimization (for example minimizing memory and disk usage while meeting an SLA on query execution time) and multi-objective balancing of performance and cost.

Target Audience

Database systems researchers and practitioners interested in query engine architecture, query compilation, and code generation for data processing will get the most from this paper, as will researchers working at the intersection of LLM agents and data management. It is also relevant to engineers deciding whether to extend an existing engine or build something new, and to readers tracking agentic system design, since the ablation study speaks directly to how multi-agent decomposition and structured inter-agent communication affect performance and cost on unseen workloads. Readers without database background can follow the central argument but will need some familiarity with OLAP concepts to interpret the benchmark results.

Authors’ abstract

Traditional query processing relies on engines that are carefully optimized and engineered by many experts. However, new techniques and user requirements evolve rapidly, and existing systems often cannot keep pace. At the same time, these systems are difficult to extend due to their internal complexity, and developing new systems requires substantial engineering effort and cost. In this paper, we argue that recent advances in Large Language Models (LLMs) are starting to shape the next generation of query processing systems. We propose using LLMs to synthesize execution code for each incoming query, instead of continuously building, extending, and maintaining complex query processing engines. As a proof of concept, we present GenDB, an LLM-powered agentic system that generates instance-optimized and customized query execution code tailored to specific data, workloads, and hardware resources. We implemented an early prototype of GenDB that uses Claude Code Agent as the underlying component in the multi-agent system, and we evaluate it on OLAP workloads. We use queries from the well-known TPC-H benchmark and also construct a new benchmark designed to reduce potential data leakage from LLM training data. We compare GenDB with state-of-the-art query engines, including DuckDB, Umbra, MonetDB, ClickHouse, and PostgreSQL. GenDB achieves significantly better performance than these systems. Finally, we discuss the current limitations of GenDB and outline future extensions and related research challenges.