Storage and execution engines have gotten much faster over the last two decades. The query optimizer has not kept up — and a VLDB demo paper from TU München argues the reason is organizational as much as technical. Optimizers are entangled with a system’s statistics, operators, and physical plans, and changing one can break workloads that depend on accidental behavior, so vendors approach them risk-averse. Even Google’s SQL systems share a frontend without sharing an optimizer.

QueryBrew sidesteps that by moving the optimizer out of the engine entirely:

  • Input SQL goes to Umbra, a state-of-the-art optimizer, producing an optimized relational-algebra DAG
  • The plan is distilled back into SQL: one named CTE per operator (scan_1, groupby_2, …), wired by referencing input CTEs — an “operator-oriented” query
  • Join order and build/probe sides are encoded in the CTEs, and target engines are forced to honor them via hints and settings
  • Statistics the optimizer needs are recomputed in SQL from native hash functions and aggregations, so no hooks into the target system are required

The target database — PostgreSQL, DuckDB, ClickHouse, SQL Server — then runs a query that already carries simplification, general unnesting, and adaptive join reordering, and can still add its own physical optimizations on top.

The numbers on a TPC-DS correlated query over a table with only 18,000 rows:

  • PostgreSQL: 40.8 s → 2.1 s (19.9x)
  • ClickHouse: 4.4 s → 0.2 s (21.8x)
  • DuckDB: 99 ms → 12 ms (8.07x)

Across the paper’s experiments, correlated and many-join queries see speedups over 100x, because the rewrites change asymptotic complexity rather than constant factors. The authors are honest about the failure mode: flattening into CTEs can hide optimizations the target engine would have found, producing slowdowns under 5x, so the rewrite is a per-query decision.

The best detail: ClickHouse 25.11 returns the wrong result for the original correlated query, and the optimized form produces the correct one — the structured query avoids the buggy code path. A reminder that query shape is not only a performance variable.

DuckDB and Microsoft are chasing similar ideas through Substrait, which requires engines to adopt a new intermediate representation. QueryBrew needs only SQL, which every engine already speaks — and getting the optimizer out of the engine is what lets it evolve on its own schedule.