Faster than Trino — now at SF10 too.
Every query differentially validated against Trino 481 — same StorageGRID Iceberg warehouse, both engines capped at 12 GB — with DuckDB's official dbgen/dsdgen as an independent data oracle.
Faster at SF1 — and now ahead at SF10
Faster than Trino at SF1 across seven of eight industry suites — and, as of this run, ahead at SF10 too.
The SF10 crossover is closed. SSB — the one suite we trailed for months (0.53× only a few weeks ago) — is now at parity (20.4s vs 21.4s) after shipping build-side key sets to workers. TPC-H (1.7×) and TPC-DS (1.5×, and now 99/99 correct at SF1) lead at SF10. Two honest exceptions we show rather than hide: TPC-C's sub-second OLTP reads at SF1, where fixed dispatch overhead dominates, and the new bank suite at SF10, where spill still degrades under an 8 GB pool — both being worked.
Scale factor ≈ dataset size: SF1 ≈ 1 GB, SF10 ≈ 10 GB. Rig: a dedicated 8-core / 31 GB box, both engines capped at 12 GB against the same StorageGRID Iceberg warehouse, Trino 481.
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. | 14.2s | 40.8s | 2.9x | 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. | 49.3s | 114.9s | 2.3x | 99/99 | 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. | 5.2s | 7.3s | 1.4x | 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. | 3.1s | 7.3s | 2.4x | 40/43 | 10.0s | 31.6s | 3.2x | 40/433 pending a LIMIT-drop regression (q17) |
| TPC-E (11) Financial-trading workload: date-range filters, point lookups against trade-history, aggregations across many small dimensions. | 3.8s | 11.6s | 3.0x | 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. | 53.7s | 480.5s | 8.9x | 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. | 10.5s | 19.8s | 1.9x | 8/8 | 370.5s | 85.5s | 0.23x | 7/8spill stalls under an 8 GB pool — fix in progress |
| 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). | 5.6s | 4.3s | 0.77x | 8/8sub-second reads — fixed dispatch overhead dominates | 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 16 August 2026 · synced from the SQE source