Snowflake, Databricks or ClickHouse? Price the workload before you pick the engine

Key points

• Every major engine now does most analytical jobs acceptably. What still differs is what each one charges for, and that is where a wrong choice shows up, usually a year after signing.
• Five properties of a workload narrow the shortlist faster than any benchmark: concurrency, latency target, idle hours, the share of work that is not SQL, and how far the data has to be shared.
• A dashboard refreshed every five minutes keeps a Snowflake warehouse with the default ten-minute auto-suspend running around the clock: about 2,960 dollars a month at list price on the smallest size, for a workload that computes for under one percent of that time.
• Running compute around the clock instead of twelve hours on working days multiplies the bill by about 2.8 on every engine that bills for running time. What differs is the hourly price of the configurations compared in Calculation 2, from about 3.58 dollars for a ClickHouse Cloud Scale setup of 12 compute units to 16.20 dollars for a medium Snowflake Gen2 warehouse.
• Apache Iceberg lowers the cost of changing engines. It does not lower it to zero, because the catalog, the access policies and the maintenance do not travel with the table.

Why does "which platform is best" produce the wrong shortlist?

Because it compares engines on what they can do, and in 2026 they can almost all do almost everything. Snowflake runs Python and serves models. Databricks runs governed SQL warehouses. ClickHouse has row policies and role-based access. BigQuery runs Spark. A feature checklist across seven vendors comes back mostly green, and a mostly green checklist decides nothing.

What does not converge is the billing unit. Snowflake charges credits for the time a warehouse is running. Databricks charges DBUs for running compute, and on classic compute the cloud provider bills the machines separately. ClickHouse Cloud charges per minute for compute units and scales to zero when idle. BigQuery on demand charges for the bytes a query reads. Redshift Serverless charges for capacity per second, with a minimum. ClickHouse, Doris and StarRocks, self-managed, charge for servers that run whether anyone queries them or not. The same workload lands very differently on each of those units, and that difference is not visible in a demo, because a demo has one user and no history.

So the useful question is narrower: given how this workload behaves, which billing unit punishes it least, and which engine was designed around that behavior? The rest of this article is a way to answer it with numbers rather than preferences.

A disclosure, since this is a comparison: Snowflake and ClickHouse are the engines we implement most often. Read our view of them with that in mind.

Which five numbers describe a workload?

Concurrency, latency target, idle hours, the share of non-SQL work, and the sharing surface. Each one can be read from query history or from the people who will use the system, and each one rules platforms in or out.

Concurrency. How many queries run at the same moment at peak. Ten analysts and three thousand customers using an embedded report are different problems even when the SQL is identical.

Latency target. The answer time users will accept. Thirty seconds is fine for a month-end report. Inside a product, anything over about a second is a defect.

Idle hours. How many hours a day nothing runs. This is the number teams almost never write down, and the one that decides whether pay-per-use pricing works for or against them.

Share of non-SQL work. How much of the workload is Python, Spark, model training or feature engineering rather than queries. Below a tenth, a SQL-first warehouse with some Python support is enough. Above a third, the engine should be built for it.

Sharing surface. Who outside the core team reads the data: other departments, customers, partners, auditors. The wider the surface, the more row-level security, masking, lineage and audit you need as standard features rather than something built in-house.

Write the five down before the first vendor call. They take a week to collect and they change the conversation, because a sales engineer can no longer demo the case that suits the product.

What is each of the seven platforms priced for?

Each engine is cheapest for the workload its billing unit was designed around, and most expensive for the opposite one. The table reads in that direction: what the platform is built for, what you pay for, and where the bill tends to surprise.

Two things the table cannot carry. First, "where the bill surprises" is not a weakness of the engine. It is a workload sent to the wrong billing unit. Second, the Iceberg column changes every quarter: the dates are there so you can check what has moved since.

What does the wrong billing unit cost in practice?

More than any difference in query speed. Below are three calculations from public list prices. They are estimates, not measurements from a client environment, and every input is stated so you can rerun them with your own numbers and your own discount.

Calculation 1: the dashboard that never lets a warehouse sleep

Snowflake suspends an idle warehouse after a set time, and the default for a warehouse created in SQL is 600 seconds. A dashboard that refreshes every five minutes sends a query before that timer ever runs out. The warehouse never suspends.

New warehouses are Gen2 by default since Snowflake's 2026_03 release, and on AWS an extra-small Gen2 warehouse uses 1.35 credits an hour (official Service Consumption Table, Table 1(b)). At the Enterprise list price of 3 dollars a credit on AWS US East, 730 hours a month is about 986 credits, or 2,960 dollars. On an older Gen1 warehouse it would be 2,190. If each refresh computes for two seconds, the warehouse does useful work for 0.67 percent of the time it is billed. Setting auto-suspend to 60 seconds, or moving the refresh to a schedule that matches when people actually look, cuts most of it. The engine is not at fault. The defaults are.

Calculation 2: the product that serves users in every time zone

Take one block of compute and run it two ways: twelve hours on 22 working days (264 hours, internal reporting), or around the clock (730 hours, a customer-facing feature). At list prices, per month:

Read the table across, not down. The three rows are not equivalent capacity: the hourly prices are not comparable until the same queries have run on each, and only your own test tells you which size of which engine meets your latency target. What the table does show holds for all three: moving from working hours to around the clock multiplies the bill by about 2.8. On Snowflake that difference is roughly 7,500 dollars a month, or 90,000 a year, before any multi-cluster scaling for peak concurrency.

Snowflake has its own answer for this workload: interactive warehouses, generally available since December 2025 in selected AWS regions, built for sub-second, high-concurrency queries. They are designed to stay on, with a minimum auto-suspend of 24 hours and a one-hour minimum charge, which confirms the point: a workload that never idles needs compute priced for running all the time. Whether that compute is cheaper inside Snowflake or in a separate engine has to be checked against the cost of the people who would run the second one.

Calculation 3: when BigQuery on demand stops being cheaper

100 slots of the Standard edition at the pay-as-you-go price of 0.04 dollars per slot-hour, kept 730 hours, cost 2,920 dollars a month. The same 2,920 dollars buys 467 TiB of on-demand scanning at 6.25 dollars per TiB. Below roughly 470 TiB a month, on demand wins.

Now take an embedded report: 300 users, 10 refreshes a day each, 22 days, 20 GiB read per refresh. That is about 1,289 TiB a month and about 8,050 dollars on demand, enough to pay for some 275 slots running permanently. The result cache helps only while the underlying data does not change, and in a near-real-time report it changes every few minutes.

The common thread: none of these teams picked a bad engine. They picked a billing unit that charges for exactly what their workload does most.

Does Apache Iceberg make the platform choice reversible?

Partly. Iceberg means the data files and table metadata can be read by another engine without an export, and in 2026 all seven platforms above read Iceberg in some form. That removes the largest single cost of leaving: rewriting and reloading the data. It does not remove the rest.

What does not travel with an Iceberg table:

The catalog. Horizon, Unity Catalog, Glue, Polaris and BigLake each hold the pointer to the current version of the table. Moving engines often means moving catalogs, and not every engine can write through every catalog. ClickHouse, for example, writes only to Iceberg tables that no catalog manages.

Access policies. Row access, masking and grants are defined in the engine or the catalog, not in the files. They have to be rebuilt and, more importantly, tested again.

Maintenance. Compaction, snapshot expiry and cleanup of orphaned files have to run somewhere, and someone pays for that compute. Frequent small writes make it worse. Iceberg keeps the option of leaving, and charges for it after every write.

The SQL on top. dbt models, views and stored logic are written in an engine's dialect. The data moves freely; the code that defines what it means does not.

So treat Iceberg as an exit you pay for in advance. For a dataset that two engines will read, or one you expect to move within three years, it is worth it. For a dataset only one warehouse will ever touch, it is overhead.

Do you need more than one engine?

Most mid-sized companies need one, and should add a second only when a single workload costs more on the first engine than the second engine costs to operate, people included. A second platform is a second bill, a second set of access policies to keep in sync, and a second thing that can fail at night.

The comparison is simple to write down. On one side: the monthly cost of the workload on your current engine, from its query history, as in Calculation 2. On the other: the infrastructure for the second engine, plus the share of an engineer's time needed to run it, plus the cost of keeping data and access policies consistent between the two. If the first number is not clearly larger, the second engine is an architecture diagram, not a saving.

Large data teams often do run two or three engines over shared Iceberg storage, and for them it pays. A team of four rarely benefits from copying that design. We would rather see one engine configured well than three configured by default.

In what order should the decision be made?

Contracts first, benchmarks last. This is the order we use, and each step can eliminate options before the next one costs anything.

What is already signed. Cloud commitments, a platform renewal date, an enterprise agreement with spend left on it. A commit on Google Cloud makes BigQuery cheap in a way no list price shows. A renewal six months away decides when a migration can start without paying twice.

The five numbers. Concurrency, latency, idle hours, non-SQL share, sharing surface. From query history where it exists, from interviews where it does not.

Who will run it. A team that writes SQL and dbt will be productive on Snowflake or BigQuery in weeks. A team that has never operated a database cluster should not start with a self-managed one, however good the benchmark looks.

The second workload. The one you will add in eighteen months. Engines are chosen for the first workload and judged on the second.

The exit. Table format and catalog, decided now. It costs little at the start and a great deal later.

A test on your own data. Two weeks, your three heaviest queries, your concurrency, your refresh pattern, with the bill read at the end. A vendor benchmark measures the vendor's workload.

What does no one publish?

An independent comparison of total cost across these platforms on the same workload. We looked. Public benchmarks measure query speed, mostly on a single table, and most are published by one of the vendors being compared. ClickBench, the most widely cited, is maintained by ClickHouse. Cost studies exist, but they are commissioned by a vendor and based on a handful of customers. Nobody has published what the same mixed workload, with real concurrency and real idle hours, costs per month on Snowflake, BigQuery and ClickHouse side by side.

That gap is why we start from the workload and calculate, and why the three examples above are calculations rather than citations. If you know of such a study with a disclosed method, we would like to read it.

Frequently asked questions

Is ClickHouse cheaper than Snowflake?

Per hour of compute on the configurations in Calculation 2, usually yes: a ClickHouse Cloud Scale setup of 12 units lists at about 3.58 dollars an hour on AWS us-east-1, against 16.20 dollars for a medium Gen2 Snowflake warehouse on Enterprise, although the two are not the same capacity. For workloads that run a few hours a day the gap narrows, because both suspend when idle. Self-managed ClickHouse is cheapest on infrastructure and most expensive in people. Test the same queries on both before comparing bills.

When is BigQuery on-demand pricing the better choice?

When the volume scanned stays below the point where reserved slots become cheaper. With 100 Standard-edition slots at list price, that point is about 470 TiB a month. Above it, or with many repeated small queries over wide tables, slots usually win.

Can Snowflake replace Databricks for machine learning?

For SQL-heavy teams with moderate machine learning needs, it can, with Snowpark and its built-in AI functions. When a large part of the work is Python, Spark and model training shared by data engineers and data scientists, Databricks is still built more directly for it.

Does choosing Apache Iceberg mean we can switch engines later at no cost?

No. The data moves without an export, but catalogs, access policies, table maintenance and SQL written in one engine's dialect still have to be rebuilt and tested.

How long does it take to collect the five workload numbers?

About a week when query history exists. Concurrency, latency and idle hours come from the history; non-SQL share and sharing surface come from a few conversations with the people who use the data.

Should we trust published benchmarks when choosing a platform?

Use them to build a shortlist, not to decide. Most are run by a vendor, on a single table, without concurrency or idle time, which are the two things that drive the bill.

‍

Want to know what your current workload costs, and what it would cost elsewhere?

We measure it on your query history, not on a benchmark, and give you the number with the method. See how cost measurement works.

‍

‍

Sources:

Snowflake Pricing Guide: on-demand 2, 3 and 4 dollars per credit (Standard, Enterprise, Business Critical) on AWS US East, storage 23 dollars per TB a month, warehouse sizes from 1 credit an hour (X-Small). Vendor list prices; contracts differ.

Snowflake documentation, Understanding compute cost: per-second billing with a 60-second minimum each time a warehouse starts.

Snowflake documentation, CREATE WAREHOUSE: AUTO_SUSPEND default of 600 seconds; GENERATION default '2'.

Snowflake Service Consumption Table, Table 1(b): Gen2 warehouses use 1.35 times the credits on AWS and GCP (X-Small 1.35, Medium 5.4), 1.25 on Azure. Gen2 default for new warehouses since bundle 2026_03.

Snowflake release note, 11 December 2025: interactive tables and interactive warehouses, general availability. Snowflake documentation, interactive analytics: minimum AUTO_SUSPEND 86,400 seconds, one-hour minimum billing.

Databricks price list, Premium, AWS: SQL Serverless about 0.70 dollars per DBU including machines; SQL Pro and All-Purpose about 0.55 dollars plus cloud machines; SQL Serverless Small 12 DBU an hour. Databricks documentation: Standard tier end of life on 1 October 2025, workspaces upgraded to Premium on AWS and GCP.

ClickHouse Cloud pricing, AWS us-east-1: compute 0.2181, 0.2985 and 0.3903 dollars per unit-hour (Basic, Scale, Enterprise), one unit 8 GiB RAM and 2 vCPU, metered per minute; storage 25.30 dollars per TB a month; internet egress from 0.1152 dollars per GB.

Snowflake release note, 26 May 2026: Apache Iceberg tables, write support by using an external query engine, general availability.

Google Cloud, BigQuery pricing: 6.25 dollars per TiB on demand, first TiB a month free; Standard edition 0.04 dollars per slot-hour pay as you go (US).

AWS Big Data Blog, Amazon Redshift Serverless at 4 RPUs: 0.375 dollars per RPU-hour in US East (N. Virginia), per-second billing with a 60-second minimum.

AWS What's New: Redshift Iceberg support GA (November 2023), writes to Iceberg tables (November 2025), Iceberg v3 tables (August 2026).

ClickHouse documentation, Writing data to open table formats: writes supported for Iceberg tables not managed by a catalog, with allow_insert_into_iceberg.

Apache Doris documentation, Iceberg Catalog.

List prices checked on [DATA SPRAWDZENIA]. Prices vary by region, cloud and contract.

‍