GenDB-V makes generated query engines fast—but the real benchmark result is 16 wrong-answer baselines
The paper reports up to 61.3× geometric-mean speedups with machine-checked code, while showing why passing synthesis tests is not enough.
GenDB-V’s largest number is a 61.3× geometric-mean speedup over DuckDB, but its most important result may be a correctness audit: the authors found valid inputs that produced wrong answers in 16 of 28 implementations generated by a testing-based baseline.
What the benchmark actually measures
The paper evaluates 22 TPC-H query templates at scale factor 100 and six SEC-EDGAR templates at scale factor 3. Each parameterized template uses three bindings. Runs cover one, 32 and 64 threads on one server with two 16-core Intel Xeon Gold 5218 processors and 384 GB of RAM. The timing protocol is one cold run followed by three hot runs, with the median hot time reported; template times are averaged across the three bindings.
Under joint storage-and-query optimization, GenDB-V reports geometric-mean speedups of 51.6× over DuckDB 1.5.6 and 22.0× over Umbra 26.08 on TPC-H SF100. On SEC-EDGAR SF3, the corresponding figures are 61.3× and 28.3×. Those are template-specialization results, not a drop-in general SQL-engine score.
The paper separately evaluates one generated general-purpose engine over the SQL fragment supported by its SQLSpec formalization. On the 22-query TPC-H SF100 workload, version 16 completes in 109.3 seconds at one thread and 9.16 seconds at 64 threads. That is 3.4× and 1.8× faster than DuckDB, and 1.52× and 1.27× faster than Umbra, at those respective thread counts.
Why the correctness result matters
GenDB-V does not ask the agent to define correctness. A deterministic translator constructs a fixed SQLSpec target, and Verus checks the generated Rust implementation and proof against it. The claimed guarantees cover SQL correctness within the declared fragment, data preservation, memory and arithmetic safety, race-free parallel execution and termination.
For comparison, the authors ran the testing-based Bespoke OLAP system through its maintained SynnoDB implementation with the same Claude Opus 5.5 setting. They then constructed valid databases that violated assumptions embedded in the generated code. Wrong answers appeared in 10 of 22 TPC-H templates and all six SEC-EDGAR templates. Examples included 32-bit arithmetic overflow, a hidden 64-line-per-order limit and assumptions that nation names are unique. One SEC-EDGAR failure also appeared on the original SF3 data for an unseen currency binding.
The boundary on the claim
This remains an author-run evaluation on one dual-socket machine, two analytical workloads and a deliberately bounded SQL fragment. TPC-H is also familiar training material, which is why the less familiar SEC-EDGAR workload is useful but not a substitute for independent reproduction. Synthesis was not free: the paper reports about $2,310 for joint template synthesis across both benchmarks and $1,229 for the general engine.
The repository publishes the system, benchmark folders, result packages and verified crates under a PolyForm Noncommercial license. The next decisive benchmark is therefore reproducibility: whether another team can regenerate the proofs and speedups on different hardware, then extend SQLSpec without weakening the fixed correctness target.
sources
comments · 0