Can LLMs Build a 10x Faster Database?

Two papers landed on arXiv the same day, from Cornell and TU Darmstadt, with the same idea: skip the general-purpose query engine and have an LLM agent compile each SQL query directly into specialized C++. GenDB and BespokeOLAP report 10x over DuckDB on TPC-H, 460x over Postgres, and per-query wins up to 1,466x. Alex Kouzemtchenko, CTO of Espresso AI, walked Papers We Love Brooklyn through both — and the interesting part of the talk is the half spent on what the numbers don’t say.

Espresso AI cuts Snowflake and Databricks bills for a living, so Kouzemtchenko’s stake in “there is real headroom in query execution” is direct. His opening read is that the headline is less interesting than the implication: DuckDB is genuinely good, and there is still an order of magnitude sitting on the table for anyone willing to abandon generality.

What “specialized” actually means

The mechanism is unglamorous and that’s the point. A general engine has to handle any aggregation, so it carries hash tables, dynamic allocation, and branching for cases your query will never hit.

If the agent knows the grouping column has exactly six distinct values, it allocates six slots and computes the index directly. No hash table, no allocation. That transformation is trivial to state, impossible to generalize, and exactly what a compiler cannot do without workload knowledge that a compiler doesn’t have.

Both pipelines take a workload specification up front — usually a benchmark suite — and treat compilation as a one-off cost amortized across every future run of those queries. Then they loop with an LLM.

GenDB keeps the optimizer in a tight loop. BespokeOLAP splits into four phases: start from DuckDB plans, add tracing and timing data, then supply reference material. Kouzemtchenko’s read on the phase structure is skeptical — the papers don’t ablate the phases individually, so how much each contributes is unknown.

His actual takeaway from the convergence curves is about feedback, not architecture: what drives improvement is giving the model information about its own performance. Expert knowledge barely enters. And the prompts turn out to be almost embarrassingly thin — a handful of bullet points summarizing a few optimization ideas.

He flags a missed connection here. These pipelines look like AutoML papers from a few years back, which are further developed — tree search, population-based methods, cross-pollination between nodes. The database papers are the only ones talking about databases, and the AutoML papers are the only ones with sophisticated search. Nobody has crossed the streams.

The cost is not the problem

Roughly $30 for GenDB, $120 for BespokeOLAP. Against a pipeline burning six figures a year, that’s rounding error. But the papers’ repos tell a fuller story: the notebooks show the benchmarks were re-run something like thirty times per query to produce stable numbers. For a research paper that’s free. For a production optimizer, thirty benchmark runs per query is a real operational cost, and Kouzemtchenko lists extrapolating across query scales — so you don’t need $10,000 of benchmarking to justify one optimization — as an open problem.

What the agents produce is a long tail. The papers classify the optimizations and many are relevant to about 1% of queries. No human would ever write them, because the engineering time isn’t justified for a niche win. When the marginal cost of trying is near zero, the calculus flips — and that, more than any single transformation, is the argument for the approach.

The ablations, read honestly

The multi-agent loop does beat single-shot generation, mostly. Lower is better on the chart, the multi-step red bars are generally faster, and on at least one workload the loop buys nothing at all. Kouzemtchenko’s verdict is that the loops are doing something real rather than being theater, but the papers don’t break the results out finely enough to say what.

A second ablation separates high-level query restructuring from low-level micro-optimization. On one dataset the micro-optimizations alone deliver a five-fold speedup; on another, essentially nothing. He reads that in both directions: you may not need to re-engineer your storage layer to get real wins, but the ceiling for the cheap path is workload-dependent and unpredictable.

Then the finding he calls a lesson for anyone writing an LLM paper. The single largest factor in the results is which model you used. The paper’s numbers came from an older model; upgrading to Opus 4.6 made things roughly four times better. He notes this is the conclusion of most agentic papers he has read recently, and it means evaluations of what is and isn’t useful have a shelf life measured in model releases. The corollary — more tokens spent yields better results — is not something either paper says out loud.

Why this isn’t in production

The correctness story is where the talk turns.

Both papers verify by running the query on both engines and comparing results. The generated code for one TPC-H query hardcodes a lookup of the known line-status values. Feed it data containing a status outside that set and the query returns wrong results — silently. It does not crash. That is the worst available failure mode, and it is a direct consequence of using execution results as the correctness oracle: your test data defines your semantics.

A collaborator looked at a second case where the generated query starts around 20 lines and grows from there, with semantics that drift subtly — whether an edge case should return zero or nothing at all. Kouzemtchenko thinks formal verification is the path forward, and that until something like it exists this doesn’t ship.

He points out the same wall shows up in text-to-SQL generally. Snowflake’s Arctic-2 work ended up hardcoding a large set of rules about top-N queries, distinct, and joins into the training pipeline — necessary, but not sufficient. With a human reviewing the SQL it’s fine. Without one, it isn’t.

There’s a related observation about file formats worth noting: the papers hint at a bigger reason for formats like Vortex, which embed WebAssembly decoders. If an LLM can generate a bespoke decoder that both the specialized engine and DuckDB can read via an extension, the interop problem that would otherwise block this work has a shape.

Trying it in anger

Kouzemtchenko closes with his own attempt. The target: an internal analytics query over query logs that tokenizes every query, extracts anything that could be a table name, and joins against a table list — deliberately over-inclusive, false positives being preferable to false negatives. It works at small scale and then DuckDB materializes an intermediate for every token and memory explodes.

He ran the BespokeOLAP approach with himself in the loop rather than fully automated, over a few hours, giving hints where he saw the shape of a fix. The agent got somewhere but stalled on data structure choices. He eventually handed it a paper and asked it to optimize using SIMD, and it did — producing roughly 3,000 lines of C++ he has no way to validate. It is not in the product. It is an experiment.

That’s the honest state of it: the technique works, the wins are real, and the verification story is not there yet.

Key takeaways

1. Both papers compile SQL into query-specific C++ via an LLM agent, treating compilation as a one-off cost amortized across repeated runs of a known workload.
2. The wins come from discarding generality — allocating exactly six slots because the grouping column has six values, rather than reaching for a hash table.
3. What drives the optimization loop is feedback about its own performance. The prompts contain almost no expert knowledge; a handful of bullet points is the whole guidance.
4. At $30 to $120 per optimization the cost is negligible, but the papers benchmarked roughly thirty times per query to get stable numbers, and that cost does not amortize the same way.
5. Many generated optimizations apply to about 1% of queries. Humans never write those because the engineering time isn’t worth it; agents make the tail affordable.
6. The largest single factor in the reported numbers is model choice — moving to Opus 4.6 improved results roughly fourfold, which puts an expiry date on every evaluation in the papers.
7. Verifying by comparing execution results means test data defines semantics. One generated query hardcodes a value lookup and silently returns wrong answers on unseen data.
8. These pipelines resemble AutoML papers that already have tree search and population methods. Neither literature cites the other, and the cross-pollination is unclaimed.

Source

Can LLMs Build a 10x Faster Database? GenDB & BespokeOLAP — Alex Kouzemtchenko (CTO, Espresso AI) at Papers We Love Brooklyn, June 2026. 18m 57s. Published 27 August 2026.

https://www.youtube.com/watch?v=bFbw7J75MQc

GenDB (Cornell): https://arxiv.org/abs/2603.02081 · repo https://github.com/SolidLao/GenDB BespokeOLAP (TU Darmstadt): https://arxiv.org/abs/2603.02001