How we run the 10 TB TPC-DS benchmark on Snowflake
We put benchmark numbers on this site, so here is the run they came from. Nothing is cut out. You see the unclustered baseline, the workload analysis, the keys Goldilox picked, and the same 99 queries a second time.
15:21
What the run produced
Those are totals across all 99 queries. The baseline is TPCDS_SF10TCL with no clustering keys on anything, which is where most tables sit until somebody tunes them. Goldilox then reads the queries that just ran, works out how the tables were being filtered, and suggests keys. We apply them and run the same 99 queries again.
Snowflake charges for warehouse time, so the credit number tracks the runtime number closely. Halve the runtime and you halve the bill for that workload.
Chapters
How the benchmark was set up
It all runs on Snowflake's own sample data, so you can reproduce it in your own account rather than taking our word for it.
| Dataset | SNOWFLAKE_SAMPLE_DATA.TPCDS_SF10TCL, 10 TB scale, roughly 57 billion rows across 24 tables |
|---|---|
| Query set | All 99 standard TPC-DS decision-support queries, run in the same order both times |
| Warehouse | 2X-Large, identical for the baseline and the optimized run |
| Baseline state | No clustering keys on any table, the state most tables are in |
| What changed between runs | Only the clustering keys Goldilox recommended. No query rewrites, no resizing, no caching tricks |
Only one thing changes between the two runs. Same data, same queries, same warehouse. Result caching is off, so the second pass really does re-read the data instead of replaying stored answers.
Why clustering keys change what a query costs
Snowflake splits a table into micro-partitions and records the smallest and largest value of every column in each one. When a query filters on a column, it checks those ranges first and skips any partition that cannot hold a match. That skipping is partition pruning, and it decides how much of the table a query actually reads.
On an unclustered table the rows sit in roughly the order they were loaded, so the values in any one column are smeared across nearly every partition. The ranges all overlap, nothing gets skipped, and a query that wants a thin slice ends up reading most of the table. A clustering key groups related values together. The ranges tighten, and Snowflake can skip far more.
Less reading means less warehouse time, and warehouse time is what you pay for. That is why the credit savings here land so close to the runtime savings, and why this kind of tuning shows up on the bill without anyone rewriting a query.
Picking the key is the difficult part. It depends on how your tables get filtered and joined in production, and you cannot read that off the schema. Goldilox works it out from the query history already sitting in your account.
Common questions
What is the TPC-DS benchmark?
TPC-DS is a decision-support benchmark from the Transaction Processing Performance Council. It models a retail data warehouse and ships 99 queries covering reporting, ad-hoc analysis, OLAP and data mining. Everyone runs the same schema, the same data and the same queries, which is what makes the results comparable.
How much can clustering keys reduce Snowflake costs?
It depends on how selective your queries are and how badly your data is currently laid out for them. In this 10 TB run it cut data scanned by 81% and compute cost by about half. If your tables are already clustered sensibly you will see less. The big wins tend to be large fact tables that get filtered on a date or ID column but are stored in load order.
Does this require rewriting any SQL?
No. Clustering happens at the storage layer. Your queries run exactly as they are and the optimizer takes advantage of the better pruning on its own, so you do not need to involve whoever owns the SQL.
How do I run this against my own workload?
Goldilox Insights installs from the Snowflake Marketplace as a Native App and runs inside your account, so your data never leaves it. It reads the queries you have already run and works out which tables are worth clustering. Each recommendation comes with an estimated credit saving, and nothing changes until you apply one. The setup guide walks you through it.
Related reading
Our first TPC-DS write-up, choosing clustering keys automatically, covers an earlier run on an earlier version of the engine. For the same approach on managed Iceberg, see Goldilox on Iceberg tables.
Want to see this on your own tables? Goldilox Insights runs inside your Snowflake account and works from the queries you are already running.
Try Free on Snowflake Marketplace