Faster than Trino — now at SF10 too.
Every query differentially validated against Trino 481 on the same StorageGRID Iceberg warehouse, with DuckDB's official dbgen/dsdgen as an independent data oracle.
Faster at SF1 — and now ahead at SF10
Faster than Trino at SF1 on all eight industry suites, and on six of seven at SF10 as of the July run.
TPC-C's sub-second reads, the one SF1 suite we trailed in July (0.77×), are now 4.9× faster than Trino. At SF10, SSB reached parity (20.4s vs 21.4s) after shipping build-side key sets to workers, and TPC-H (1.7×) and TPC-DS (1.5×) lead. The remaining exception is the bank suite at SF10, where spill degraded under an 8 GB pool in July; the memory-pool and spill fixes from October have not been measured at SF10 yet.
Scale factor ≈ dataset size: SF1 ≈ 1 GB, SF10 ≈ 10 GB. SF1 figures are from the 10 October 2026 sweep against Trino 481. SF10 figures are from the 9 July 2026 run on a dedicated 8-core / 31 GB box, both engines capped at 12 GB; SF10 has not been re-run against Trino since.
SQE run duration over time — pick a suite, zoom in. Updated on each sync from the raw benchmark results.
The eight suites — what each measures, and how we do
| Suite & purpose | SF1 | SF10 | ||||||
|---|---|---|---|---|---|---|---|---|
| SQE | Trino 481 | Speedup | Pass | SQE | Trino 481 | Speedup | Pass | |
| TPC-H (22) 22-query decision-support benchmark — the most widely benchmarked SQL workload and SQE's primary comparison target. | 12.6s | 32.6s | 2.6x | 22/22 | 66.5s | 111.9s | 1.7x | 22/22 |
| TPC-DS (99) 99-query decision-support benchmark — larger and harder than TPC-H; pushes joins, window functions, and grouping sets. | 34.2s | 95.9s | 2.8x | 98/99q64 returns no rows on either engine since a data-generator change | 216.6s | 320.5s | 1.5x | 98/99 |
| SSB (13) Star Schema Benchmark — 13 queries over one fact joined to four dimensions; the shape data warehouses are optimised for. The suite we trailed longest. | 3.2s | 5.5s | 1.7x | 13/13 | 20.4s | 21.4s | 1.0x | 13/13crossover closed — parity |
| ClickBench (43) 43 queries over one wide table — log analytics: heavy string filters, point lookups, and counts. SQE's caching shines here. | 1.7s | 4.8s | 2.8x | 41/43the other 2 return no rows on either engine | 10.0s | 31.6s | 3.2x | 40/43July run; not re-measured since |
| TPC-E (11) Financial-trading workload: date-range filters, point lookups against trade-history, aggregations across many small dimensions. | 0.7s | 4.8s | 7.2x | 11/11 | — | — | test-only | 18/18SF10 diff needs ~14 GB for the 10M-row result — validated test-only |
| TPC-BB (10) BigBench mixed workload: structured analytics plus JSON and text operations over a retail warehouse schema. | 25.4s | 96.5s | 3.8x | 10/10 | 405.5s | 1429.7s | 3.5x | 10/10 |
| Bank (8) Purpose-built banking workload — customer / KYC / accounts with day-partitioned transactions; time-windowed "last 14 days out of N" scans that lean on partition pruning. | 12.0s | 37.7s | 3.1x | 8/8 | 370.5s | 85.5s | 0.23x | 7/8July run: spill stalled under an 8 GB pool; October spill fixes not yet measured at SF10 |
| TPC-C (8 read) The read SELECTs from the TPC-C OLTP workload — point lookups against small Iceberg tables (SQE runs the read subset, not transactions). | 1.1s | 5.3s | 4.9x | 8/8 | 5.0s | 18.0s | 3.6x | 8/8 |
Zero row differences between SQE and Trino across every run — each non-match is a case where both engines agree (0 rows). Two exceptions we show rather than hide: TPC-C's sub-second OLTP reads at SF1 (0.77×, fixed dispatch overhead dominates when a query finishes in milliseconds) and the new bank suite at SF10 (0.23×, spill stalls under an 8 GB pool — being fixed). Full per-query method: docs, or run it yourself via the benchmark quickstart.
How it got fast — and still is
- 12 Jun 2026
The benchmark that lied
Differential validation with DuckDB as an independent oracle: caught 16 vacuous TPC-DS queries and a Trino rounding bug (q75).
Read the story → - 16 Apr 2026
- 14 Apr 2026
- 12 Apr 2026
Current as of 19 October 2026 · synced from the SQE source