Featured
Databricks SQL vs. Snowflake: Up to 5× Faster & 4× Lower Cost for ETL
Benchmarking ETL with the TPC-DI: Databricks SQL Serverless Warehouses vs. Snowflake Gen1 and Gen2 Warehouses
By Shannon Barrow Réda Khouani
UPDATED 6/30/2025!
Based upon the enormous feedback (and often significant pushback) from the Snowflake community we RERAN tests based upon guidance from the Snowflake product team.
- Did we get the results wrong and why?
- If so, how much of an impact did properly splitting files have on Snowflake ETL performance?
- Did it change the narrative and what else can we learn from the Snowflake community backlash?
Watch the video below to find out!
Note: This is the second part of a multi-part blog series about benchmarking data engineering and ETL workloads using the TPC-DI specification. Per TPC policy, this series does not report on official benchmark results. Refer to part 1 of the blog series for an introduction to the benchmark and other notes about how we test using this benchmark. Subsequent blogs in the series are dedicated to platform comparisons and lessons learned.
In the introductory blog, we introduced the ETL benchmark based upon the TPC-DI and reviewed some historical Databricks metrics in the benchmark. For the remainder of the series, we will compare the performance and TCO on this benchmark to other cloud-based platforms as well. The most recent tests using this benchmark were conducted on Snowflake, which we were eager to test after their announcement of “Generation 2” warehouses in early May 2025.
The appendix contains more details about the testing scope, but in summary:
This series compares platforms at the 10,000 scale factor (~1TB raw data).
- Focuses exclusively on Databricks SQL Serverless Warehouses and Snowflake Data Warehouses (Gen1 and Gen2)
- Benchmark executed on Azure for both platforms
- Orchestration by dbt on both platforms
Before reviewing the standard 10,000 scale factor, we will discuss the challenges we faced testing large files on Snowflake and the modifications we made to the test to accommodate Snowflake.
Benchmark Results Summary
The benchmark results show that Databricks SQL Serverless outperforms Snowflake Gen1 and Gen2 warehouses in ETL workloads using the TPC-DI benchmark. Even after modifying the test to accommodate Snowflake’s limitations with large files, Databricks SQL Serverless is
- 4.7x faster with 4.4x better TCO than Snowflake Gen1
- 2.8x faster with 3.4x better TCO than Snowflake Gen2
Challenges Testing Snowflake and Changes Made
UPDATED 6/30/2025:
Review the video linked at the top of this blog to learn how we got around the challenges testing Snowflake.
The original version of this blog reflected our issues testing large files on Snowflake. Parallelization of file reads is NOT default behavior in Snowflake, whereas it is OOTB behavior on other platforms.
The initial version of the blog cited the issues getting parallel reads, however, to get the test completed on Snowflake we split the files into 1GB chunks. That is no longer necessary as the Snowflake product team guided us to the methods to getting parallel reads (part of which appears to be undocumented):
- MULTI_LINE=FALSE
- COMPRESSION=’NONE’
- Create table from @stage directly instead of having a view or external table over the files (this we couldn’t find documented anywhere)
Nonetheless, the benchmark is now running as expected without splitting the files. Make sure to review the video above for these details AND additional NEW tests and analysis!
Results: Databricks vs Snowflake On Original Files
THESE RESULTS REFLECT THE UPDATED RESULTS ON 6/30/2025 AFTER MODIFYING SNOWFLAKE CODE TO GET PARALLEL READS
Databricks SQL Serverless is:
4.3x faster with 4.1x better TCO than Snowflake Gen1 warehouses.
2.8x faster with 3.6x better TCO than Snowflake Gen2 warehouses.
Since the originally published blog only gave the 10k scale factor results on the split up data, the metrics here vary only in the slightest. The originally published blog reflected Gen1 with 4.7x worse perf (4.3x worse TCO) but that has lowered to 4.1x worse perf (4.1x worse TCO). The performance gap is the same for Gen2 as it was in the original blog (2.8x).
Conclusion
Overall, we recognize that ETL performance has improved with Gen2 warehouses over Gen1 warehouses. However, most customers will still see a 4.3x performance gap in ETL compared to Databricks SQL Serverless Warehouses. Even lucky customers in a region with Gen2 availability (there are only four total regions) would still be paying 3.6x more for ETL jobs than Databricks SQL Serverless.
Also, the community has begun publishing Gen2 test results of their own, including this one on YouTube, which found a flat TCO change, and Josue Bogran’s Blog from 6/7/2025, which actually shows Gen2 having very marginal Ad-hoc SQL performance improvements and thus higher TCO than Gen1. If some workloads become cheaper on Gen2 (ETL) and other workloads only increase customer total costs (Ad-hoc SQL), then one begins to question whether there is a net value with Gen2 warehouses. In fact, pairing the ad hoc SQL test presented by Josue in his blog linked above with the results of this ETL test, Databricks SQL outperforms Snowflake Gen1 and Gen2 warehouses in both ETL and in BI/adhoc SQL.
Stay tuned for part 3 of this ETL benchmark blog series: Benchmarking Dataproc against Databricks Photon Jobs Cluster!
Appendix
Testing Scope
- This series compares platforms at the 10,000 scale factor (~1TB raw data).
- Why 10,000 Scale Factor: 20,000 is too difficult to generate the raw data (refer to part 1 of this blog series about data generation limitations with the TPC-provided JAR), and anything less than 1,000 is too trivial. Even the 1,000 scale factor completes on Databricks for as little as 50 cents or less. All scale factors below 1,000 cost pennies on Databricks and provide negligible insights for practitioners
- The scope of this test focuses exclusively on Databricks SQL Serverless Warehouses and Snowflake Data Warehouses (Gen1 and Gen2). Serverless data warehouses are chosen for this comparison to align with Snowflake, despite potential cost savings with traditional job clusters.
- Tests were conducted on AWS, where Snowflake’s Gen2 warehouse price premium is 35%. Refer to the appendix for pricing variations.
- To orchestrate the pipeline’s execution, we leverage dbt Core for its simple translation across platforms and to ensure consistent testing for each CDW. The dbt code is in the same git repo but under its own folder. This dbt version of code is NOT integrated with the rest of the code and is a standalone reference placed in the repo for easy access. To execute the dbt code, you will need to install dbt on your local machine and execute as a standalone execution method. Some modifications of the dbt version of the code may be required to successfully complete in your respective Databricks or Snowflake environments.
- TL;DR: We built the dbt code specifically for a standalone Snowflake and Databricks test and therefore it exists as standalone code that we are providing as a reference point. Perhaps we will integrate the Databricks side of the dbt code to run as another option with the “normal” TPCDI Driver Notebook, but that is a future improvement. - Results are OOTB — no modified settings or properties are being passed to either platform
- The system under test looks like the following diagram:
Minor Code change for Snowflake implementation
Other than minor syntax changes, the only code change worth mentioning was replacing FactMarketHistory function calls for getting the minimum and maximum stock ticker price over the previous 52 weeks, along with the date it occurred (the earliest date upon tie). We execute this on Databricks using MAX_BY()/MIN_BY(). However, Snowflake doesn’t support MAX_BY()/MIN_BY() functions with sliding window frames. Therefore, we replaced it with a different window function that seemed to execute as expected. For example:
FIRST_VALUE(OBJECT_CONSTRUCT('dm_low', dm_low, 'dm_date', dm_date)) OVER (
PARTITION BY dm_s_symb
ORDER BY dm_low ASC, dm_date ASC
ROWS BETWEEN 364 PRECEDING AND CURRENT ROW
) AS fiftytwoweeklowSeveral approaches, including min/max with self-joins and staging temporary results, were explored, but none surpassed the performance of the FIRST_VALUE() implementation. While we are not Snowflake development experts, we did strive to optimize the code for Snowflake’s environment. We welcome any feedback or suggestions from experienced Snowflake data engineers regarding more efficient or refined solutions and are willing to adapt the code accordingly, as we would be for any other portions of the code.
Calculating Costs
In terms of sizing and pricing approaches, Snowflake warehouses are somewhat similar to Databricks. Select a t-shirt size for your warehouse (for simplicity), and the warehouse scales out within the cloud to handle higher concurrency workloads. Each charges a standard SKU price and scales the number of “credits” up depending on the t-shirt size of the warehouse (instead of credits, Databricks uses “DBUs”, but the concept is the same). If the warehouse scales out to handle higher concurrency, then users are charged for each cluster of the warehouse. The scale-out handles automatically with no user intervention.
Scaling out is disabled for this test to keep the test fair and calculate costs much more easily. Warehouse sizes are chosen with the best TCO and Performance combination for each scale factor. We take care in aligning warehouses by price, though the 2 platforms don’t often carry commonly priced warehouse sizes. See the chart below for the list prices we use for this comparison:
Performance and TCO Actuals
Actual spreadsheet tracker is PUBLIC now for transparency!

