
Estuary and CorrDyn benchmarked 7 cloud data warehouses: Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric, ClickHouse, and MotherDuck. The study evaluated 244 queries across datasets ranging from 1 GB to 1 TB, with concurrency tests involving up to 100 simultaneous sessions.
One key result that reframed the whole study:
At 1 GB and 10 GB, buying sixteen times the compute bought you somewhere between 0.8 and 1.5 times the speed.
On small data, the biggest size was sometimes the slower one. The "size up for speed" instinct that vendor pricing pages encourage can mean paying more for less.
That one number is the whole argument in miniature: there is no "best" cloud data warehouse, and "which one is fastest" is the wrong question. The right answer depends on your workload, how many people query at once, and what you're willing to spend per hour - and it changes, a lot, as any of those move.
See How All 7 Cloud Data Warehouses Compare
Compare performance, cost, and scalability across 7 cloud data warehouses.
Why We Benchmarked 7 Cloud Data Warehouses
If you search for the fastest or most cost-efficient cloud data warehouse, you get a lot of confident answers and very little audited evidence. None of the seven engines here holds a current, audited TPC-DS result, and every vendor publishes a benchmark that happens to flatter its own design. The independent comparisons that do exist vary one thing at a time: one configuration, or a compute sweep for a single user, or a concurrency test at one size.
Nobody had measured the whole thing together - engine, compute size, data volume, number of simultaneous users, and kind of query: as one map. So we decided to fill this gap, and take on the task of measuring the performance of these warehouses. We used Estuary to load data into all of them: one capture of the source fed all seven warehouses from the same stored copy, so every engine got the exact same rows, generated once. That is a large part of why the comparison is fair, and it is Estuary's only role in the results: the pipeline, not a contestant.
Cloud Data Warehouse Benchmark Methodology
The benchmark evaluated seven cloud data warehouses across different query types, data volumes, compute configurations, and concurrency levels.
- 7 engines: Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric, ClickHouse, MotherDuck.
- 244 benchmark queries from three public suites - TPC-DS and DSB for join-heavy reporting (201 queries), ClickBench for scan-heavy event analytics (43 queries).
- Data volumes from 1 GB to 1 TB, at every compute size each vendor offers.
- 1 to 100 simultaneous sessions, to show what happens when a team - or an AI agent firing off queries in bursts - actually shows up.
Every engine ran untuned, on its default layout, with automatic scaling switched off, so each number tells you what one unit of compute does with a given amount of data and a given number of users.
4 Key Findings From the Cloud Data Warehouse Benchmark
The benchmark produced dozens of measurable results. Four of them actually change the decision:
- Size to your data, not your ambitions. Bigger compute only pays off when the data is large enough to use it. Where that line sits is different for every engine.
- Plan against "useful concurrency," not single-query speed. Single-user speed is what vendors demo. It tells you little about what happens when a whole team (or a set of AI agents) hits the warehouse at once, and the price of handling that varies enormously between engines.
- Joins vs. scans reorders the leaderboard. Whether your queries join several tables or scan one wide table moved the rankings more than any change in compute size. The engine that suits your event dashboards is often not the one that suits your finance reports.
- How an engine bills idle time matters as much as its hourly rate. Most warehouses sit idle most of the time, and the seven handle that very differently, which can matter more to the invoice than the per-query price.
At 1 GB and 10 GB, increasing compute by 16x delivered only 0.8x to 1.5x query speed in the tested configurations. Bigger warehouses don't always mean faster queries.
The full benchmark explores these findings in detail, including engine-by-engine performance results, compute configurations, concurrency comparisons, and cost considerations.
Three reputations we put to the test
Engine choice usually happens before anyone runs a query, based on reputation. The study wrote down each engine's reputation as of mid-2026, then set the measurements next to it. Three of them are worth testing yourself:
- Redshift: "the legacy engine you migrate away from."
- MotherDuck: "a small-data tool that falls over past laptop scale."
- Microsoft Fabric: "not performance-competitive."
Some held up, some didn't, and one was only half true. The report shows which, and by how much.
What's Inside the Full Cloud Data Warehouse Benchmark?
The blog is the trailer. The report is where you make an actual decision:
- A decision guide that takes your query type, your concurrency target, and your cloud commitment and points you to one or two engines and a starting compute size.
- Short profiles of all seven engines - what each is built for, what it did well, how to size it, and what to watch out for.
- The concurrency grid and the cost tables behind every finding.
- The four buyer archetypes (small team, product company, terabyte-scale enterprise, already-on-a-platform) with a recommendation for each.
- Everything open-sourced: the benchmark code, the per-engine query files, and the raw results database with every run, including the failures, so you can reproduce it, add an engine, or challenge the findings. Challenges to the findings are welcome.
Find the Right Cloud Data Warehouse for Your Workload
FAQs
Does a bigger warehouse mean faster queries?
What is useful concurrency?
Do joins versus scans matter when choosing a data warehouse?
How was the benchmark run, and is it reproducible?

About the author
Team Estuary is a group of engineers, product experts, and data strategists building the future of real-time and batch data integration. We write to share technical insights, industry trends, and practical guides.















