Apache Spark vs VecRuntime on TPC-DS 1 TB, AWS Graviton4

VecRuntime runs Spark SQL's filters, projections, aggregates, sorts and joins on Arrow-layout batches with the Java Vector API -- on the JVM, no native code -- and moves batches between executors over its own Arrow Flight shuffle. This page compares it against plain Apache Spark on the TPC-DS 1 TB workload on Amazon EKS with AWS Graviton4 (arm64) nodes, and sets both against the published x86 run from the same day, with the same settings and the same single-AZ layout (its own cluster session) (#253).

Summary

Graviton4 against x86

The x86 numbers are the published run: 9 x m5.4xlarge (16 vCPU, 64 GB, AVX-512), the same data, executors, Spark settings and single-AZ layout, measured the same day in its own cluster session.

"G/x" is the query's time on Graviton4 over its time on x86 (below 1 = faster on Graviton4).

Benchmark infrastructure

Methodology. The two engines ran one after another on the same nodes, each alone on the cluster, over the same S3 data with the same Spark settings; only the execution engine and its own memory split differ (every engine has 50 GB per executor). Each query ran once after the plan was compiled; the time is the wall-clock of the query's execution as the runner measures it.

Test environment

Versions

Configuration

Common to both engines:

spark.sql.shuffle.partitions=300
# spark.sql.adaptive.advisoryPartitionSizeInBytes left at Spark's default (64 MB); no coalescePartitions.minPartitionNum
spark.eventLog.enabled=true

VecRuntime:

spark.plugins=io.vecruntime.spark.VectorPlugin
spark.shuffle.manager=org.apache.spark.sql.vecruntime.shuffle.VectorShuffleManager
spark.vecruntime.exec.strictFloatingPoint=false   # Comet's default too
spark.vecruntime.shuffle.aqe.mapSizeScaling=true   # AQE sees Spark-scale map output sizes (#514)
spark.vecruntime.shuffle.aqe.sparkCompressionRatio=0   # the uncompressed-bytes ratio (#514)
AOT class-data cache off
--add-modules=jdk.incubator.vector --enable-native-access=ALL-UNNAMED (driver and executors)

The arm64 platform

• HotSpot on Graviton4: UseSVE=2, MaxVectorSize=16 -- the Vector API's species are 128 bits wide, as on NEON.
• VecRuntime's platform probe picks its SVE paths: native compress (SVE COMPACT) for selection, and the broadcast-AND-compare lane masks, because VectorMask.fromLong is not intrinsified at 128-bit SVE on JDK 25 (#253, #484).
• The native codecs (snappy, zstd, lz4) and Netty's epoll transport load their aarch64 libraries; neither architecture has libhadoop, as on x86.

Performance results

Per query

Seconds per query on Graviton4, both engines side by side (hover for values; click a legend entry to hide an engine).

Performance distribution

Top 10 improvements

Regressions

Notes

• Both engines returned the same row counts on every query and the same checksums on every query except q65, whose result has ties that each engine orders differently.
• Both legs ran on 2026-09-30 in one cluster session, Spark first and VecRuntime straight after, on the same nine nodes in one availability zone, each alone on the cluster. S3 throughput varies between sessions, so only runs from the same session are compared.
• The earlier Graviton4 runs (2026-09-26 at 1.23x, 2026-09-29 at 1.26x) had their nodes split across two availability zones; this run keeps all nine in one and adds #554.
• VecRuntime reports its map output sizes to AQE on Spark's scale (#511, #514): its columnar shuffle is 1.6-4.3x smaller than Spark's for the same rows, and without the scaling AQE packs up to twice Spark's rows into a task.
• The x86 reference ran the same day with the same image version, settings and single-AZ layout, in its own cluster session; the architecture comparison below therefore compares two sessions.

All queries

Running the benchmark

The cluster runner, the Spark-on-Kubernetes manifests, the image and the data generation are in the benchmark runner's README; on Graviton the image builds for arm64 on an arm64 node and the runs select the arm64 node group. run-matrix.sh writes one JSON-lines result file per run; this page is rendered from two of them, with the x86 page as the reference, by benchmarks/scripts/render-graviton-page.py.

TPC-DS is a benchmark of the Transaction Processing Performance Council; these results are not audited TPC results and are not comparable to published TPC-DS results. Times are one measured iteration per query on the cluster described above; run-to-run variation on the heavy queries is a few percent.