The 114.75× wildcard-join result is real—and tightly scoped

A new database paper reports a striking peak: its wildcard-join implementation reaches 4.59 queries per second on the hardest of three 32-thread queries, versus 0.15 queries/s for DuckDB 1.4.4 and 0.04 queries/s for unmodified Umbra. Those measurements imply the paper’s quoted 30.6× advantage over DuckDB and 114.75× over Umbra’s baseline.

The result deserves attention, but not compression into “SQL LIKE is now 114× faster.” The authors built a specific physical operator inside Umbra. It decomposes %- and _-wildcard patterns into literals and positional constraints, indexes the literals in an Aho–Corasick automaton, and matches many patterns in one pass rather than evaluating every row-pattern pair with a nested-loop join.

What the benchmark actually tests

The accompanying Hacker News workload uses about 3.9 million 2025 archive records, plus a 1,000-pattern blocklist and 1,000 topic patterns. Tests ran entirely in memory on one AMD Ryzen 9 9950X machine with 16 cores, 32 hardware threads and 32 GB of DRAM.

Across the three multithreaded join queries, the new operator produced 59.69 queries/s on Query 1 and 1.03 queries/s on Query 2; the paper says each was at least 4.2× the competing baselines. Query 3 produced the much larger 114.75× peak. That distribution matters: the headline is a worst-baseline, single-query maximum, not a geometric mean over a broad suite.

The single-thread experiment strengthens the algorithmic case. On Query 3, the prototype reached 1.13 queries/s against DuckDB’s 0.014 queries/s, an 81.3× gap, while baseline Umbra exceeded the 180-second timeout. This makes the result harder to dismiss as merely a parallel-scaling artifact.

The useful boundary

The paper separately compiles constant LIKE filters into specialized code. On its filter-heavy stress query, that path was 13.3× faster than DuckDB and 14.3× faster than baseline Umbra. Yet an inline-table join was not always preferable: compiled filters led by as much as 7.2× with two patterns, and the automaton join only moved ahead at 64 patterns, reaching 65.8 queries/s versus 52.8.

There is also a stated pathological case. Highly repetitive patterns such as %a_aa_aaa_aaaa...% over repetitive text can cause an Aho–Corasick output explosion and push execution back toward quadratic behavior. The authors leave detection and fallback handling for future work.

The practical reading is therefore narrower—and more valuable—than the headline. This is evidence that wildcard joins deserve a dedicated operator once pattern tables become large. It is not yet evidence that every LIKE workload, engine or hardware profile will see a triple-digit gain. Independent reproduction across more engines and less curated pattern distributions is the next test.