Benchmarks

TPC-H at SF=1 / SF=10 / SF=100, all 22 queries on an Apple M4 Max — ematix-flow vs DuckDB, Polars, single-node PySpark, and Postgres. Median ms, same hardware and same Parquet files.

Same-machine TPC-H benchmark (Apple M4 Max, single-node) over all 22 queries at three scale factors — SF=1 (~1 GB, fits in cache), SF=10 (~10 GB, production shape), and SF=100 (~100 GB, out-of-core). Five engines, the same Parquet files, the same machine. Switch scale with the tabs:

Scope: every number here is single-node. ematix-flow also has an auto-detected distributed mode (Arrow Flight peer mesh — see Why ematix-flow). A cross-host cluster-scale panel is deferred to a later release; the harness (tpch_distributed) already ships in the repo.

How to read it

• ematix-flow + DuckDB are co-measured in one process (10 timed trials after 3 warmups, medians) — the head-to-head that matters, so thermal drift hits both equally.
• Polars runs the same in-process harness (hand-translated q??.polars.sql where its planner rejects the canonical shape).
• PySpark runs local[*] out-of-process on the JVM via bench-tpch-pyspark.py, against the same files.
• Postgres 14 runs each query under EXPLAIN ANALYZE (B-tree indexed + ANALYZEd), reported as the planner’s Execution Time.
• The fastest engine per row is highlighted; ematix-flow’s column is tinted for scanning.

What changes across scale

At SF=1 the working set is L3-resident and per-query constant cost dominates — ematix-flow’s fused aggregate / filter paths take all 22. At SF=10 and SF=100 the workload turns memory- then IO-bound: DuckDB’s mature join-order heuristics and vectorised kernels reclaim a handful of multi-fact joins (Q08 at SF=10; Q10 / Q20 / Q22 at SF=100), while ematix-flow still leads the field (21 / 22 then 18 / 22) and widens specific wins — most visibly Q18 at SF=100: 495 ms vs DuckDB’s 2 812 ms (5.7×), from the scale-relative broadcast-join rule.

Caveats

• Polars can’t run several canonical TPC-H shapes; we feed it semantically-identical hand-translated variants. Q05 still overflows Polars’s default 32-bit row index (the bigidx build would fix it) and shows ”—” at SF=10 / SF=100; a few more SF=100 queries (Q08, Q10, Q19, Q21) likewise exceed it.
• Postgres is a row-store OLTP engine, included as a familiar single-node reference — not a columnar-analytics peer. At SF=100 it ran with a 90 s per-query cap; 16 / 22 heavy queries timed out (shown ”—”), so its SF=100 geomean covers only the 6 that finished.
• DuckDB runs at defaults (in-memory read_parquet). ematix-flow runs the production preset — target_partitions = cores, plus the fused-aggregate, dict-group-count, push-LeftSemi, runtime-bloom, and scale-relative-broadcast rules. That’s the same config you get from pip install ematix-flow; no per-query tuning.
• Thermal note (SF=10 / SF=100): back-to-back runs on an M4 Max drift ~5–20 % as the package heats. ematix-flow and DuckDB move together, so the head-to-head holds — which is exactly why the two are co-measured in a single process.

Reproducing

# ematix-flow + DuckDB + Polars — same harness, swap the data dir per scale
TPCH_DATA_DIR=examples/tpch/data/sf1 \
  cargo run --release -p ematix-flow-core \
  --example tpch_triangulation_bench --features triangulation
#   → sf10, then sf100 (SF=100 wants ~64 GB free + a few minutes/run)

# PySpark — needs JDK 17+ (brew install openjdk)
JAVA_HOME=$(/usr/libexec/java_home) \
  SPARK_DRIVER_MEM=16g SPARK_SHUFFLE_PARTS=64 \
  python scripts/bench-tpch-pyspark.py \
  --data-dir examples/tpch/data/sf100 --trials 5 --warmups 1

# Postgres — load the Parquet via ematix-flow's own ADBC ingest,
# then run each query under EXPLAIN ANALYZE.

The 2026-06-07 ematix/DuckDB/Polars refresh re-runs the harness above; the carried PySpark/Postgres raw logs are in bench-results/refresh-2026-05-30/ (same machine). Release-over-release history lives in the repo CHANGELOG.