GenDB — LLM-Powered Generative Query Engine

✨ Demo<br>About<br>Why<br>Leaderboard<br>Models<br>Languages<br>Roadmap<br>Team<br>Paper<br>GitHub

The Next Generation of<br>Query Processing

GenDB is a Generative Query Engine that uses LLM agents to generate instance-optimized<br>query execution code, tailored to your specific data, workloads, and hardware.

Read the Paper &rarr;<br>View on GitHub<br>✨ Try the Interactive Demo &rarr; NEW

☝ Interactive guided tour &bull; Step-by-step visualization &bull; Try your own data

3.2x

faster than DuckDB on TPC-H

6.8x

faster than DuckDB on SEC-EDGAR

462x

faster than PostgreSQL on TPC-H

280x

faster than PostgreSQL on SEC-EDGAR

What is GenDB?<br>Synthesized, Not Engineered

Five specialized LLM agents collaborate through a structured pipeline to generate<br>optimized storage, indexes, and standalone native executables — all tailored to the specific data, workload, and hardware.

Agent 1

Workload Analyzer

Profiles hardware, samples data, extracts workload characteristics

Agent 2

Storage Designer

Designs layouts with encoding, compression, indexes, and zone maps

Agent 3

Query Planner

Generates resource-aware execution plans adapted to data and hardware

Agent 4

Code Generator

Implements plans as optimized native code with SIMD and parallelism

Agent 5

Query Optimizer

Iteratively refines code using runtime profiling feedback

Why GenDB?<br>A Third Option

Today, every new use case demands either a painful extension or an entirely new system:

Option 1 — Extend an existing system

PostgreSQL &rarr; PostGIS, TimescaleDB, pgvector, Citus, AGE …

Each extension fights the host system&rsquo;s architectural constraints.

Option 2 — Build a new system

DuckDB, Umbra, ClickHouse, Milvus, Pinecone, InfluxDB, Neo4j …

Each requires years of engineering and huge monetary costs.

Option 3 — Generate

Use LLMs to generate per-query execution code . No extension wrestling, no multi-year engineering. New techniques become reachable through prompt updates.

Performance

Instance-optimized code exploits exact data distributions, join selectivities, group cardinalities, and hardware characteristics. No general-purpose engine can match this.

Extensibility

Integrating new techniques requires prompting, not re-engineering. Semantic queries, GPU-native code — all reachable through prompt updates.

Economics

80% of queries repeat in 50% of clusters. Generation cost is amortized over many executions, making it cost-effective for recurring analytical workloads.

Leaderboard<br>Performance Rankings

Total query execution time across all queries. GenDB variants use different LLM backbone models.<br>All systems run on identical hardware with full parallelism enabled.

TPC-H (SF10, ~10GB)

SEC-EDGAR (3yr, ~5GB)

System<br>Total Time<br>vs. Best GenDB<br>Relative

System<br>Total Time<br>vs. Best GenDB<br>Relative

Model Comparison<br>Generation Cost & Speed

Different LLM backbone models offer different trade-offs between generated code quality, generation time, and cost. Ranked by average query execution time.

Language Comparison<br>C++ vs Optimized C++ vs Rust

We select the best-performing C++ binary for each TPC-H query from a GenDB run, then give<br>Claude Code (Opus 4.6) 5 iterations to analyze, profile, and improve —<br>first for optimized C++, then for a full Rust rewrite.

Original C++

GenDB-generated code with standard compilation.

241 ms

total (5 queries)

Optimized C++

Aggressive flags, madvise tuning, parallelized joins, thread optimization.

185 ms

total — 1.30x faster

Rust

Full rewrite with rayon, memmap2, unsafe bounds-check elimination.

283 ms

total — competitive main_scan

Query<br>Original C++<br>Optimized C++<br>Rust<br>Best

Q1<br>49.8 ms<br>39.2 ms<br>71.7 ms<br>Opt. C++

Q3<br>25.0 ms<br>26.0 ms<br>52.5 ms<br>Orig. C++

Q6<br>31.8 ms<br>35.5 ms<br>23.7 ms<br>Rust

Q9<br>85.4 ms<br>64.4 ms<br>101.9 ms<br>Opt. C++

Q18<br>49.2 ms<br>20.1 ms<br>32.8 ms<br>Opt. C++

Total<br>241.2 ms<br>185.2 ms<br>282.6 ms<br>Opt. C++ (1.30x)

Key findings: Optimized C++ achieves a 1.30x overall speedup, with Q18 showing the largest gain (2.44x) from parallelized join building.<br>Rust wins on Q6 (zone-map scan with get_unchecked) but carries ~30ms per-query overhead from mmap page table setup, penalizing short queries.<br>The Rust main_scan compute times are competitive with C++, suggesting the overhead is structural rather than algorithmic.<br>We plan to introduce a dedicated Code Refiner agent to the pipeline, responsible for low-level, implementation-level optimizations — to automatically achieve these gains as part of the standard GenDB workflow.

Roadmap<br>What&rsquo;s Next

GenDB is under active development. Every step follows three principles:

Higher Quality

More Robust

Lower Cost

Completed

OLAP Workloads

Multi-agent pipeline for analytical queries. Evaluated on TPC-H and SEC-EDGAR, outperforming DuckDB, Umbra, ClickHouse, MonetDB, and PostgreSQL.

In Progress

Self-Evolving Agent Memory

Agents learn from past runs, accumulate optimization experience, and improve generation quality over time — without retraining the...