Making DuckDB Faster: An Honest Optimization Campaign

Repository: ~/duckdb-ks/duckdb (upstream clone @ e500d7786, work on branch ks-opt-regex, final commit 04c94c4c4) · Machine: 32-core x86-64 VM, 125 GB RAM, Ubuntu 24.04 · August 2026

1. Goal and the honesty contract

The task: optimize DuckDB itself against its official and standard academic benchmark suites, with a stated target of 5× per suite. Every measurement in this report obeys a strict no-cheating contract:

2. Benchmarks used

SuiteQueriesKind
TPC-H sf122Official industry standard (decision support)
TPC-DS sf199Official industry standard (decision support)
IMDB / JOB113Academic standard (Join Order Benchmark)
h2oai (group/join)15Standard db-benchmark (group-by / join)
ClickBench43Industry standard analytics (web-log workload)

ClickBench q24 fails the runner's answer verification in the unmodified stock build (a pre-existing upstream nondeterminism with tied ORDER BY rows); it is excluded identically on both sides of every comparison.

3. Final result

Geometric-mean speedup of the final optimized stack vs. the stock release build 1.00× 1.10× 1.20× 1.30× 1.152× TPC-H 1.184× TPC-DS 1.215× IMDB/JOB * 1.234× h2oai * 1.237× ClickBench * * held out from all profile training — darker bars prove the gains generalize
Figure 1 — Final interleaved A/B results (answers verified, q24 excluded on both sides).
SuiteGeomean speedupTotal time (stock → optimized)
TPC-H sf11.152×0.54s → 0.47s
TPC-DS sf11.184×3.14s → 2.68s
IMDB/JOB1.215×9.31s → 7.94s
h2oai1.234×1.89s → 1.51s
ClickBench1.237×— (q24 excluded from totals)

Notable single-query win: ClickBench q28 (a REGEXP_REPLACE-dominated query over ~100M rows) improves ~1.73× in the final stack (1.79× from the source-level regexp work alone, re-verified at 1.76× after the post-review fix).

4. What the optimized stack consists of

source change: regexp / RE2 fast paths clang-18 build -march=native thin-LTO (cross-module inlining) PGO (3-stage, held-out) BOLT (code layout) The five layers of the final stack (each kept only after it won its own A/B test) Reproducible via scripts/ks-optimized-build/{build_optimized.sh, bolt.sh} committed in the repo
Figure 2 — Optimization pipeline.

4.1 Source-level: regexp engine (commit d565d7427 + 04c94c4c4)

Profiling showed ClickBench q28 spends 77% of its CPU in the vendored RE2's BitState backtracking engine (used when capture groups are required and the one-pass engine does not apply). Two general-purpose changes:

4.2 Build-level

LayerOwn contribution (interleaved A/B)
clang-18 + -march=native (vs gcc-13 portable)~1.1–1.15× typical; mixed per-suite alone
thin-LTO + PGO (trained TPC-H/TPC-DS/micro)tpch 1.159×, tpcds 1.126×, imdb 1.181×, h2oai 1.230×, clickbench 1.211×
BOLT (instrumentation mode, ext-tsp layout)tpch 1.043×, tpcds 1.032×, imdb 1.217×, h2oai 1.024×, clickbench 1.019× extra

gcc PGO+LTO was also built and measured — it lost to clang on every suite and was discarded. jemalloc was already DuckDB's allocator (nothing to change).

5. What was tried and honestly rejected

IdeaMeasuredVerdict
gcc -march=native alone0.91–1.16×, regressions on tpcds/imdbrejected
gcc PGO+LTO+nativeworse than clang equivalent on all suitesrejected
Row-based aggregate Combine (rewrite of the finalize-phase merge in GroupedAggregateHashTable) q32 1.088×, q18 1.142×, h2oai q10 1.078×; but full-suite geomeans only 1.006×/1.011× — below the pre-registered 1.05× keep bar rejected per protocol; fully-tested patch preserved at ~/duckdb-ks/patches/s2-row-based-aggregate-combine.patch (a solid per-query win worth upstreaming)
Benchmark-setting knobs (thread pinning, insertion-order, etc.)rejected as cheating

6. Functionality: nothing is broken

7. Process and audits

8. The 5× goal, honestly

The requested 5× per-suite speedup was not achieved, and in my assessment it is not achievable honestly on this codebase. The final verified result is 1.15–1.24× per suite (with individual queries up to 1.76×). For context: DuckDB is one of the most heavily optimized analytical engines in existence — its own team lands single-digit-percent wins per operator per release, and the gap to the fastest research engine (Umbra) on ClickBench is roughly 3–4× on identical hardware, achieved only through fundamentally different architecture (compiled queries), not incremental optimization. A genuine 5× on TPC-H/TPC-DS/JOB/ClickBench simultaneously would surpass every published engine result; any change that appeared to deliver it within this task's scope would almost certainly be a benchmark-integrity violation (e.g. caching results, weakening verification, or gaming settings), which the task forbids and which I did not do. Every number above is reproducible from the committed scripts and the raw CSVs in ~/duckdb-ks/harness/results/.

9. Deliverables