TPC-H 1 TB in 80 Seconds: GizmoSQL on AWS Graviton5 (vs. Graviton4 and Azure Cobalt 100)

AWS made its Graviton5-based R9g and R9gd instances generally available on August 31, 2026. Four days later I ran our standard TPC-H 1 TB benchmark on one. GizmoSQL ran all 22 queries in a combined 80.475 seconds on a single r9gd.24xlarge. At $7.69 per hour on-demand, that is $0.17 of compute for the whole run.

To know how much of that is the new chip, I ran the identical benchmark the same afternoon, with the same GizmoSQL and DuckDB build, on two other 96-vCPU Arm machines: the Graviton4 equivalent, an r8gd.24xlarge in the same AWS region, and the Azure Cobalt 100 shape our previously published number came from, a Standard_E96pds_v6. Graviton4 took 89.831 seconds. Cobalt 100 took 106.806 seconds. So on this workload Graviton5 is 10% faster than Graviton4 and 25% faster than Cobalt 100, core for core, and it wins every one of the 22 queries against the Azure box. Because the run is shorter, it is also no more expensive per run despite the highest hourly price of the three.

This post covers exactly how the benchmark is run, the three machines side by side, every per-query timing from all three runs, and what I think it says about Arm in the cloud.

The headline numbers

All three machines have 96 vCPUs, all three are memory-optimized shapes with local NVMe, and all three are Arm. All three runs happened within about an hour of each other on September 4, 2026, with the same GizmoSQL build, the same DuckDB v1.5.5 engine, the same data, and the same operator. That is as controlled as a cross-cloud benchmark gets. For the record, our previously published Azure number was 108.88 seconds; today's 106.806 on the same shape shows that DuckDB moved about 2% in the interim, so the gap to Graviton5 is almost entirely hardware.

Methodology

I run every cloud the same way, so the numbers are comparable across providers and across time. Nothing here is tuned per query.

1. Provision a VM with local NVMe

I pick the instance family in the target cloud with local NVMe drives, because analytics at this scale is a storage-bandwidth problem as much as a CPU problem. On AWS that is the d suffix (r9gd, r8gd); on Azure it is the d in E96pds_v6. Network block storage would add a variable I do not want in the measurement.

I also deliberately stop at 96 vCPUs. All three of these shapes are a single NUMA node: every core sees every byte of memory at the same latency. The 192-vCPU 48xlarge sizes are two NUMA nodes (two sockets on Graviton4; two memory regions on Graviton5's single 192-core die), and a single DuckDB process that has to pull hash tables across the NUMA boundary does not scale anywhere near linearly. More on that below.

2. Stripe the NVMe drives into one RAID 0 volume

The drives arrive as separate raw devices. I combine them into a single RAID 0 array so DuckDB sees one fast volume with the aggregate throughput of all the drives. RAID 0 has no redundancy, which is fine here: the data is a reproducible benchmark set and the volume is ephemeral by design.

# Three NVMe drives on the r9gd/r8gd 24xlarge; the Azure VM had six
sudo mdadm --create /dev/md0 --level=0 --raid-devices=3 \
  /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
sudo mkfs.ext4 -F /dev/md0
sudo mkdir -p /data && sudo mount /dev/md0 /data

3. Copy the TPC-H scale factor 1,000 Parquet data onto the volume

The dataset is TPC-H at scale factor 1,000, roughly 1 TB uncompressed, stored as Parquet with one directory per table. I generate it with our open-source tpch-datagen utility, which uses DuckDB and multiprocessing to produce the tables in parallel, and stage it in object storage so every run starts from identical bytes. Copying it onto the RAID 0 volume is not part of the timed run.

4. Ingest the Parquet into GizmoSQL tables

With GizmoSQL pointed at a fresh DuckDB database file on the NVMe volume, I load each table with a CREATE TABLE ... AS SELECT over a glob of that table's Parquet directory. Eight tables, eight statements:

CREATE TABLE lineitem AS SELECT * FROM read_parquet('/data/tpch/sf1000/lineitem/*.parquet');
CREATE TABLE orders   AS SELECT * FROM read_parquet('/data/tpch/sf1000/orders/*.parquet');
CREATE TABLE customer AS SELECT * FROM read_parquet('/data/tpch/sf1000/customer/*.parquet');
CREATE TABLE part     AS SELECT * FROM read_parquet('/data/tpch/sf1000/part/*.parquet');
CREATE TABLE partsupp AS SELECT * FROM read_parquet('/data/tpch/sf1000/partsupp/*.parquet');
CREATE TABLE supplier AS SELECT * FROM read_parquet('/data/tpch/sf1000/supplier/*.parquet');
CREATE TABLE nation   AS SELECT * FROM read_parquet('/data/tpch/sf1000/nation/*.parquet');
CREATE TABLE region   AS SELECT * FROM read_parquet('/data/tpch/sf1000/region/*.parquet');

Ingest time is also not part of the benchmark number. The point of the benchmark is query performance against native DuckDB storage, which is how GizmoSQL runs in production.

5. Run the 22 queries, in order, three times each

The runner is our open-source benchmark-flight-sql tool. It connects to the GizmoSQL server over Apache Arrow Flight SQL, exactly like a real client would, and executes the standard 22 TPC-H queries in order. Each query runs three times back to back before moving on to the next. Every run's wall-clock time and row count are written to a JSON file.

benchmark-flight-sql \
  --hostname ec2-XX-XX-XX-XX.us-east-2.compute.amazonaws.com \
  --port 443 \
  --username scott \
  --password '...' \
  --num-query-runs 3

6. Average each query, then sum the averages

For each query I take the mean of its three runs. The benchmark figure is the sum of those 22 means. That is the 80.475 seconds. Note that this is deliberately not "best of three": the first run of each query is usually the slowest because the operating system page cache is cold, and it counts.

All three, query by query

Mean of three runs per query, in seconds; shorter is better. Graviton5 is the shortest bar in all 22 groups. The label on the right is how much less time Graviton5 took than Cobalt 100 on that query. Hover a bar for its exact value.

Graviton5 · r9gd.24xlargeGraviton4 · r8gd.24xlargeCobalt 100 · E96pds_v6

Show the raw numbers (all three runs per query)

Straight from the runner's output files; all 66 executions succeeded on every machine. The two ratio columns divide the Graviton5 mean by the Graviton4 and Cobalt 100 means, so 0.74 means Graviton5 took 74% of the time.

Query	G5 run 1	G5 run 2	G5 run 3	G5 mean (s)	G4 mean (s)	Cobalt mean (s)	G5 / G4	G5 / Cobalt
Q1	5.35	1.69	1.68	2.905	3.913	4.738	0.74	0.61
Q2	0.85	0.47	0.55	0.624	0.700	0.851	0.89	0.73
Q3	2.69	2.50	2.50	2.561	2.709	3.323	0.95	0.77
Q4	3.09	2.23	2.37	2.563	3.184	3.718	0.81	0.69
Q5	2.31	2.06	2.34	2.237	2.593	3.273	0.86	0.68
Q6	0.60	0.62	0.58	0.599	0.732	0.793	0.82	0.76
Q7	1.82	2.00	2.31	2.042	2.272	2.816	0.90	0.73
Q8	2.02	1.82	2.50	2.115	2.491	3.381	0.85	0.63
Q9	14.16	13.57	13.86	13.865	14.744	17.420	0.94	0.80
Q10	6.05	4.30	4.48	4.947	5.874	5.909	0.84	0.84
Q11	1.20	0.84	0.50	0.847	0.905	1.070	0.94	0.79
Q12	1.39	1.58	1.64	1.537	1.695	2.122	0.91	0.72
Q13	7.55	8.72	8.81	8.360	8.926	9.660	0.94	0.87
Q14	3.23	2.15	2.07	2.487	2.407	3.182	1.03	0.78
Q15	1.37	0.97	1.18	1.173	1.217	1.568	0.96	0.75
Q16	2.53	2.12	1.95	2.199	2.207	3.792	1.00	0.58
Q17	2.52	2.05	2.77	2.446	2.819	3.719	0.87	0.66
Q18	9.73	10.27	10.22	10.075	10.811	11.462	0.93	0.88
Q19	2.53	2.72	2.34	2.530	3.074	3.498	0.82	0.72
Q20	2.68	2.53	2.62	2.611	3.089	3.961	0.85	0.66
Q21	8.17	12.03	8.85	9.686	11.318	13.783	0.86	0.70
Q22	2.46	1.78	1.96	2.066	2.151	2.767	0.96	0.75
Total	84.29	79.04	78.10	80.475	89.831	106.806	0.90	0.75

A few things worth noticing:

• Graviton5 wins 20 of 22 against Graviton4 and 22 of 22 against Cobalt 100. Versus Graviton4, Q14 and Q16 are a wash (within run-to-run noise) and everything else is 4% to 26% faster. Versus Cobalt 100, the smallest win is 12% (Q18) and the largest is 42% (Q16), with Q1 close behind at 39%.
• The scan-heavy queries gained the most. Q1 (a full pass over the six-billion-row lineitem table) dropped 26%, and Q4, Q6, Q19, Q10, and Q20 each dropped 15% to 19%. These are the queries that stream columns through the CPU as fast as memory will feed them, which is exactly where Graviton5's faster DDR5-8800 memory should show up.
• The big joins gained less. Q9, Q13, and Q18, the three heaviest multi-way joins, improved 6% to 7%. They are still where the time goes: those three plus Q21 account for about 42 of the 80 seconds on Graviton5.
• The cold pass is where the Azure box hurts most. Pass one totals 84.3 s on Graviton5, 96.1 s on Graviton4, and 117.9 s on Cobalt 100; Q1's first run alone is 5.4 s, 7.5 s, and 10.0 s respectively. If you only report warm runs, you would quote 78 seconds for Graviton5. We do not.
• Twelve of the 22 queries finish in under 2.5 seconds on a terabyte of data, over the network, through a Flight SQL client. That is the part that still feels unreal to me.

Why Graviton5 is the real deal

Ten percent over Graviton4 might not sound like a headline, so let me put it in context. This is a single generation, on a workload that is bound by memory bandwidth and NVMe throughput rather than by per-core arithmetic, measured with zero software changes: I did not recompile, retune, or touch a single setting between any of the three runs. The same binary just ran 10% faster than on Graviton4 and 25% faster than on Cobalt 100, and the Graviton5 run cost 2% less than the Graviton4 run despite the instance costing 9% more per hour. That is free performance, and it compounds with every DuckDB release.

AWS's own claims for the chip explain where it comes from:

• Up to 25% higher compute performance per vCPU versus Graviton4. We saw 10% on an I/O- and memory-heavy analytical workload; compute-bound workloads should see more.
• DDR5-8800 memory, up from DDR5-5600 on Graviton4. Analytical SQL at this scale streams columns through the CPU, and memory bandwidth is the ceiling. That lines up with the scan-heavy queries gaining the most.
• Five times the L3 cache of Graviton4. Hash joins and aggregations over hundreds of millions of groups live or die on cache hit rates, and Q9, Q18, and Q21 are exactly that kind of query.
• Up to 192 vCPUs in the largest sizes. I used the 24xlarge, with 96, to keep the core count identical to the other two runs. There is a 48xlarge with double the cores and memory waiting for the next round.

The honest caveats: each machine got one benchmark run, on a Thursday afternoon, so a percent or two of any gap is noise. The Azure box has 672 GiB of memory to AWS's 768 GiB, and different NVMe (six 880 GiB drives versus three 1,900 GB), so the cross-cloud comparison folds in the platform, not only the CPU. And Cobalt 100 is Microsoft's first-generation Arm chip; Graviton5 is Amazon's fifth. The Graviton5 versus Graviton4 comparison is the clean one, and it is the one I would quote: same cloud, same region, same instance layout, one generation apart, 10% faster. The 48xlarge is next on my list.

What it costs

The math is simple: seconds, divided by 3,600, times the on-demand hourly price.

Graviton5   80.475 s ÷ 3,600 × $7.689/hr = $0.172
Graviton4   89.831 s ÷ 3,600 × $7.054/hr = $0.176
Cobalt 100 106.806 s ÷ 3,600 × $5.616/hr = $0.167

All three round to $0.17 per full TPC-H 1 TB run, the figure we have published for a while now, which means our comparison against the cloud warehouses does not change on cost: GizmoSQL is still about 16x cheaper per run than Snowflake, 31x cheaper than Databricks SQL, and 138x cheaper than BigQuery on this workload. What changes is speed. At 80.5 seconds, GizmoSQL is now faster than every one of them, including Snowflake's 103.4 seconds, which had previously edged us out on runtime while costing 16 times more.

And those are on-demand prices. Spot pricing on Graviton instances is typically a fraction of on-demand, and for a batch analytics job that finishes in 80 seconds, spot is a perfectly reasonable place to run.

The horse race is the point

Here is the part I care about more than any single number. GizmoSQL is one process that runs on one machine, and it is built on DuckDB, which is compiled for Arm and gets faster every release. That means every time a cloud provider ships a better CPU, every GizmoSQL user gets the improvement the same day, for free, by changing one string in a launch script. No re-platforming, no new pricing tier, no waiting for a vendor to "support" the new instance type. Today that string was r9gd.24xlarge.

And the race is far from over:

• Azure Cobalt 200 is Microsoft's answer to exactly this result. It is a 132-core chip on Arm Neoverse V3 and TSMC 3 nm, and Microsoft claims more than 50% higher performance than Cobalt 100 across real workloads. If even half of that lands on TPC-H, Cobalt 200 would leapfrog Graviton4 and land right next to Graviton5. Microsoft says general availability comes later in 2026. We will run this exact benchmark on it the week it is available.
• Google Cloud Axion is the third Arm contender. The C4A family is built on Neoverse V2, the same core generation as Graviton4, and its -lssd shapes ship with up to 6 TiB of local Titanium SSD, which is what this benchmark wants. C4A tops out at 72 vCPUs, so it is not a like-for-like 96-core run, but GizmoData Cloud already provisions GizmoSQL on C4A and an Axion result belongs in this table. It is coming.
• The 48xlarge sizes, and NUMA. Doubling to 192 vCPUs on either generation also means going from one NUMA node to two, and in my experience that is where linear scaling for a single DuckDB process goes to die: hash joins and aggregations that fit comfortably in one socket's memory suddenly spend their time shuttling across the interconnect. Graviton4's 48xlarge is two 96-core sockets. Graviton5's is one 192-core die with two NUMA regions, and AWS says the inter-core latency is about a third lower, so it may be the first 48xlarge where the second node pays for itself on this workload. Measuring that, and whether two NUMA-pinned GizmoSQL processes beat one big one, is a post of its own.

Amazon, Microsoft, and Google are each spending billions to make their Arm chips beat the other two. Snowflake, Databricks, and BigQuery customers see those gains as whatever margin the vendor decides to pass along, if any. GizmoSQL customers see all of it, at the hourly price of the VM. That is the structural advantage of a single-node engine on commodity cloud hardware, and it gets bigger every generation.

Reproduce it

Everything here is open source and the steps are the ones above. The data generator is gizmodata/tpch-datagen, the query runner is gizmodata/benchmark-flight-sql, and GizmoSQL Core is free, Apache-2.0, and installs in one command. If you get a different number on the same shape, I want to hear about it.

If your team is paying a warehouse by the credit, the DBU, or the byte scanned to answer questions like these, this is what one right-sized Arm VM does for $0.17. We will help you move the workload, and we guarantee the bill drops by half.