Back to Devoured - October 29, 2026
DEVOURED
The 2026 Cloud Data Warehouse Benchmark (Website)

The 2026 Cloud Data Warehouse Benchmark (Website)

Data Estuary
A comprehensive 2026 benchmark of seven cloud data warehouses reveals that performance and cost depend heavily on query type and workload concurrency.
What: The study tested Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric, ClickHouse, and MotherDuck across join-heavy (TPC-DS, DSB) and scan-heavy (ClickBench) workloads. MotherDuck led in single-user speed for join queries, while Databricks showed the most stable scaling from 1 GB to 1 TB.
Why it matters: The industry lacks a single 'best' engine; choosing one requires matching the engine's specific architecture (e.g., column scan vs. join optimization) to the specific workload and concurrency requirements.
Takeaway: Use the benchmark's buyer's guide to map your specific workload—join-heavy or scan-heavy—to the appropriate engine size before committing to a provider.
Decoder
  • Scale Factor (SF): A standard metric in database benchmarks where SF1 corresponds to roughly 1 GB of data, and SF1000 corresponds to 1 TB.
  • TPC-DS: A decision support benchmark consisting of complex, join-heavy SQL queries used to evaluate the performance of data warehouses.
  • ClickBench: A benchmark specifically designed to test analytical query performance for read-heavy workloads on single wide tables.
Original article

The 2026 Cloud Data Warehouse Benchmark

This benchmark ran 244 queries on seven cloud data warehouses (Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric, ClickHouse and MotherDuck) at five or more compute sizes each, on 1 GB to 1 TB of data, first with one person querying and then with up to 100 sessions at once. For each size it records how fast queries ran, how many did not complete, and what the compute costs at list price.

There is no best data warehouse; the right one depends on your workload and your requirements. This site lets you understand the tradeoffs and select the best data warehouse for your workload.

What the benchmark measured

  • Seven engines, each run on five to eight of its compute sizes (ClickHouse on five single-replica and eight three-replica sizes), with automatic scaling switched off so that each result describes one fixed unit of compute. Fabric is the exception: its smoothing of bursts cannot be switched off.
  • 244 queries in three public suites. TPC-DS (99 queries) and DSB (102 queries) are join queries, the kind most reports and dashboards run; DSB repeats the same reports on skewed data. ClickBench (43 queries) contains scan queries over one wide table of web page views.
  • Four data volumes for the join queries: about 1 GB, 10 GB, 100 GB and 1 TB (the scale factors SF1 to SF1000). The scan queries run on one table of about 100 GB.
  • One person, then many. Every query ran one at a time (the single-user pass), and then under bursts of 1, 5, 10, 20, 50 and 100 simultaneous sessions (the concurrency grid). The sessions share one queue of queries. The scan suite has 43 queries, so on scan queries the highest level is all 43 at once.
  • The same data in every engine. Estuary loaded one copy of the data into all seven, so every engine answered the same questions over the same rows.

Three questions to answer when choosing a warehouse

  1. Do your queries join tables, or scan one wide table? Reports and dashboards built by a business intelligence tool usually join tables. Event, telemetry and product dashboards usually scan one table.
  2. How many people will have a query running at the same moment? This is usually much smaller than the number of people who use the warehouse. If one in ten of 400 people is querying at any moment, that is 40.
  3. What hourly spend would you approve? Compare engines at that spend, since each engine's fastest size is also its most expensive.

Size to your data volume: a bigger size pays off only when the data is large enough to use it

Plan for the number of people querying at once

ClickHouse did not finish the join queries at 100 GB but placed third on scan queries

Before you compare hourly rates, check how each engine bills idle time

Every hourly price here assumes the compute is busy. Most warehouses are quiet for much of the day, and the seven engines bill quiet hours very differently. The table below summarizes each vendor's public documentation as of . The benchmark did not measure idle time.

What to keep in mind when reading these results

  • No engine's physical layout was tuned. No clustering, distribution or sort keys, partitioning or hand-built statistics were applied. A well-tuned deployment can do better, and engines built to be tuned (Redshift, BigQuery) are the most affected.
  • One unit of compute, with autoscaling off. Several engines add clusters or capacity under load in production. The results show what one unit does.
  • Warm engines, three measured runs. Cold starts, data loading and writes were not measured, and small differences between engines should be read as ties.
  • List prices. Costs use each vendor's published rates from July to October 2026. Negotiated discounts are outside the study.
  • MotherDuck ran untranslated. The queries were written in DuckDB SQL and checked against DuckDB, so MotherDuck alone ran them without translation.
  • Translated SQL on every engine. The join queries were translated mechanically from DuckDB's dialect for each engine, with small correctness fixes on five of them. The scan queries use the SQL published in the ClickBench project for each engine, apart from Fabric's, which the study translated.
Explore all 58 articles in today's digest

Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi