# Snowflake vs BigQuery: how they differ in compute, price and features

Snowflake and BigQuery are both cloud data warehouses that keep storage apart from compute and run SQL at any size. The main difference is how you pay for queries. In Snowflake you run virtual warehouses, sized from X-Small (1 credit an hour) upward, billed by the second while they run, with a 60-second minimum each time one starts. In BigQuery there is nothing to size. On demand you pay for the bytes each query reads, $6.25 per TiB in the US after the first free TiB each month, or you buy slots by the hour in an edition. Snowflake runs on AWS, Azure and Google Cloud; BigQuery runs on Google Cloud. Choose Snowflake for steady workloads you can size and for more than 1 cloud, and BigQuery for spiky or occasional queries on Google Cloud with nothing to manage.

- Page: https://tecyfy.com/data-engineering/snowflake-vs-bigquery
- Part of: Data engineering (https://tecyfy.com/data-engineering)

- **Snowflake** (Snowflake Inc., https://docs.snowflake.com/en/user-guide/intro-key-concepts): A cloud data platform where data sits in central storage and queries run on virtual warehouses, compute clusters you size, start and stop.
- **BigQuery** (Google Cloud, https://cloud.google.com/bigquery/docs/introduction): Google Cloud's serverless data warehouse, where queries run on slots that BigQuery assigns, paid by the bytes each query reads or by slot capacity.

Both warehouses answer the same SQL at the same scale, and both keep storage apart from compute, so the data can grow without the query engine growing with it. They part ways on what you manage and what you are billed for. Snowflake gives you compute to size and charges for the time it runs. BigQuery gives you no compute to see and, on demand, charges for what each query reads.

## What each one is

**Snowflake** keeps every table in its own storage, split into micro-partitions automatically, and runs queries on virtual warehouses. A warehouse is a cluster you name and size: X-Small uses 1 credit an hour, each size up doubles the credits, and query speed generally grows with the size. It runs only while there is work, suspending after the idle time you set and resuming on the next query, and it is billed by the second. A team can have a warehouse for loading, another for dashboards and another for data science, each sized for its job. Snowflake runs on AWS, Azure and Google Cloud.

**BigQuery** is Google Cloud's serverless warehouse. There is no cluster: each query gets slots, BigQuery's units of compute, from a shared pool. On demand you pay for the bytes a query reads, so how a table is laid out decides the bill: a query that filters on the partition column reads only those partitions. For steady loads you can buy slot capacity in an edition instead, and the bytes no longer matter.

## Side by side

| | Snowflake | BigQuery |
| --- | --- | --- |
| **Compute** | Virtual warehouses you create and size, from X-Small up, each doubling the last. They suspend when idle and resume on the next query. | Slots (virtual CPUs) that BigQuery assigns to each query. You cannot set the number a query uses. |
| **How queries are billed** | Credits for the seconds a warehouse runs, with a 60-second minimum each time it starts. X-Small is 1 credit an hour, Small 2, Medium 4. | On demand, the bytes each query reads, $6.25 per TiB in the US with the first TiB each month free. Or slot-hours in the Standard, Enterprise or Enterprise Plus edition. |
| **What costs money when nobody queries** | Storage, and a warehouse until it suspends. Auto-suspend is on by default. | Storage, and slot commitments if you bought them. On demand, nothing. |
| **Many users at once** | A multi-cluster warehouse (Enterprise Edition) adds clusters as queries queue, up to the maximum you set. | Queries share the slots available; when they ask for more, the extra work waits in a queue. |
| **Data layout** | Every table is split into micro-partitions of 50 to 500 MB uncompressed, automatically. A clustering key keeps related rows together on large tables. | You choose partitions (by day, hour, month, year or a range) and up to 4 clustering columns. A partition filter can be required on every query. |
| **Going back in time** | Time travel for 1 day by default, up to 90 days in Enterprise Edition, then Fail-safe. | Time travel for 7 days by default, settable from 2 to 7, then 7 days of fail-safe. |
| **Copies and sharing** | Zero-copy clones, and Secure Data Sharing with other accounts with no data copied. | Table clones charged only for the data that differs, and BigQuery sharing (formerly Analytics Hub) with no data copied. |
| **Clouds** | AWS, Azure and Google Cloud, in many regions of each. | Google Cloud. |
| **Open table formats** | Apache Iceberg tables, managed by Snowflake or an outside catalog. | Apache Iceberg managed tables in Cloud Storage. |
| **Machine learning in SQL** | Snowpark for Python, Java and Scala, and Snowpark-optimized warehouses for memory-heavy work. | BigQuery ML creates and runs models in SQL, and calls Google's AI models. |

## Which one fits

- **Queries that run all day at a steady rate:** Snowflake. A warehouse sized to the load and kept busy costs the same whatever each query reads, and you can predict the bill from the hours.
- **Occasional or spiky queries, with no one to manage compute:** BigQuery. On demand there is nothing to start, size or suspend, and nothing is billed between queries.
- **Data on AWS or Azure, or on more than 1 cloud:** Snowflake. Snowflake runs in AWS, Azure and Google Cloud regions, so the warehouse can sit next to the data. BigQuery runs on Google Cloud.
- **Already on Google Cloud, with data arriving through Pub/Sub or Cloud Storage:** BigQuery. BigQuery is Google Cloud's own warehouse, and Pub/Sub can write messages straight into a BigQuery table.
- **Many analysts querying at the same moment:** Snowflake or BigQuery. A multi-cluster Snowflake warehouse adds clusters as queries queue; in BigQuery, queries share the slots and the work waits for free ones, so buy enough slots for the busiest hour.
- **A cost that a bad query cannot blow up:** Snowflake or BigQuery. A Snowflake warehouse costs the same per second however much a query reads, and resource monitors cap credits. In BigQuery on demand, require a partition filter and set a maximum of bytes billed.

## The same table in each

The same table and query in each: orders kept by day, and revenue by day and country for 2 days. Both were run on a laptop, Snowflake's SQL on fakesnow (which runs it on DuckDB) and BigQuery's on the open-source BigQuery emulator, and both returned DE 162.00 and FR 80.50 on 14 October, DE 60.00 and IN 15.25 on 15 October. The emulators check the SQL and the result, not the bill.

### Snowflake: `orders.sql`

```sql
-- Rows kept together by day. Snowflake splits the table into micro-partitions itself.
create or replace table orders (
  order_id string, country string, amount number(10, 2), ordered_at timestamp_ntz
)
cluster by (to_date(ordered_at));

insert into orders values
  ('o-1', 'DE', 120.00, '2026-10-14 09:12:00'),
  ('o-2', 'FR', 80.50, '2026-10-14 11:40:00'),
  ('o-3', 'DE', 42.00, '2026-10-14 18:05:00'),
  ('o-4', 'IN', 15.25, '2026-10-15 07:30:00'),
  ('o-5', 'DE', 60.00, '2026-10-15 13:55:00');

-- Runs on the warehouse in use. The bill is the seconds it runs, not the bytes it reads.
select to_date(ordered_at) as order_date, country, sum(amount) as revenue
from orders
where to_date(ordered_at) between '2026-10-14' and '2026-10-15'
group by order_date, country
order by order_date, country;
```

No partitions to declare: Snowflake splits the table into micro-partitions as rows arrive. The cluster by is optional and only pays on large tables. The query runs on the warehouse the session uses, and its cost is the seconds that warehouse runs, the same whether it reads 1 day or a year.

### BigQuery: `orders.sql`

```sql
-- One partition per day, and rows in each day sorted by country.
create or replace table shop.orders (
  order_id string, country string, amount numeric, ordered_at timestamp
)
partition by date(ordered_at)
cluster by country
options (require_partition_filter = true);

insert into shop.orders values
  ('o-1', 'DE', 120.00, timestamp '2026-10-14 09:12:00'),
  ('o-2', 'FR', 80.50, timestamp '2026-10-14 11:40:00'),
  ('o-3', 'DE', 42.00, timestamp '2026-10-14 18:05:00'),
  ('o-4', 'IN', 15.25, timestamp '2026-10-15 07:30:00'),
  ('o-5', 'DE', 60.00, timestamp '2026-10-15 13:55:00');

-- The date filter is required: it limits the scan, and the bill, to the days asked for.
select date(ordered_at) as order_date, country, sum(amount) as revenue
from shop.orders
where date(ordered_at) between '2026-10-14' and '2026-10-15'
group by order_date, country
order by order_date, country;
```

The layout is part of the table: a partition a day, sorted by country inside each, and require_partition_filter makes BigQuery reject any query without a date filter. On demand, the date filter decides the bill, because only the partitions it names are read.

The SQL is nearly the same; the difference is in what each file says about cost. In BigQuery, the table's `partition by` and `require_partition_filter` exist because the bytes read are the bill: a query without a date filter is refused before it can read every day. In Snowflake, nothing in the file touches the bill. The same query costs the seconds the warehouse runs, so the levers are elsewhere: the warehouse's size, how fast it suspends, and whether a clustering key helps a large table prune micro-partitions.

## Things that trip people up

- **A BigQuery `limit` does not cut the bill.** On demand, a query is charged for the data it reads, and on a table that is not clustered, `select * ... limit 10` costs the same as without the limit. Select the columns you need, filter on the partition column, and check the bytes first with a dry run.
- **A Snowflake warehouse that never suspends bills all day.** Each query that arrives before the auto-suspend time keeps it running. A dashboard that refreshes every few minutes can keep a warehouse up around the clock.
- **Snowflake's 60-second minimum.** Each start is billed for at least a minute, so a warehouse that suspends after a few idle seconds and wakes for many small queries pays that minute again and again.
- **BigQuery slots queue rather than fail.** With capacity pricing, a busy hour does not raise the bill; queries wait for slots instead. Watch queue times, not just cost.
- **Time travel windows differ.** Snowflake's default is 1 day and BigQuery's 7. Do not count on Snowflake's history for longer than you have set.

## Pricing your own workload

The prices behind these sums are on Tecyfy, read weekly from each maker: the [Snowflake cost calculator](/data-engineering/snowflake-cost) prices warehouses by size, edition and region, idle time and storage, and the [BigQuery cost calculator](/data-engineering/bigquery-cost) prices on-demand queries and slots in each edition. For Snowflake against Databricks on the same hours, see [Snowflake vs Databricks](/data-engineering/snowflake-vs-databricks). How a table is laid out matters to both, and [partitioning and clustering](https://tecyfy.com/concepts/data-partitioning) explains how pruning works on each.

## Questions

### What is the difference between Snowflake and BigQuery?

Both are cloud data warehouses with storage apart from compute. In Snowflake you size virtual warehouses and pay for the seconds they run; in BigQuery there is no compute to size, and you pay for the bytes each query reads or buy slot capacity. Snowflake runs on AWS, Azure and Google Cloud, and BigQuery on Google Cloud.

### Is Snowflake or BigQuery cheaper?

It depends on the shape of the work. Steady queries that keep a warehouse busy favour Snowflake, because the cost follows the hours, not the bytes. Occasional queries on well-partitioned tables favour BigQuery on demand, where nothing is billed between queries and the first TiB each month is free. Price your own workload with the Snowflake and BigQuery cost calculators.

### Does BigQuery have warehouses like Snowflake?

No. BigQuery assigns slots, its units of compute, to each query, and you cannot set how many a query uses. With an edition you buy slot capacity in reservations, which is the closest thing to sizing a warehouse.

### How does Snowflake bill a warehouse?

In credits for the time it runs, by the second, with a 60-second minimum each time it starts. An X-Small uses 1 credit an hour and each size up doubles it. A credit's price depends on the edition and region, from $2 in Standard Edition on AWS US East (Northern Virginia).

### Do Snowflake and BigQuery support time travel?

Yes. Snowflake keeps history for 1 day by default and up to 90 days in Enterprise Edition. BigQuery keeps it for 7 days by default, settable from 2 to 7. Both then keep deleted data for 7 more days for recovery by the vendor (Fail-safe in Snowflake, fail-safe in BigQuery).

### Can I run Snowflake on Google Cloud?

Yes. Snowflake runs on AWS, Azure and Google Cloud, so a Google Cloud company can choose either. The deciding questions are then how you want to pay for compute and which features you need.

## Sources

- [Key concepts and architecture](https://docs.snowflake.com/en/user-guide/intro-key-concepts)
- [Overview of warehouses](https://docs.snowflake.com/en/user-guide/warehouses-overview)
- [Multi-cluster warehouses](https://docs.snowflake.com/en/user-guide/warehouses-multicluster)
- [Micro-partitions and data clustering](https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions)
- [Understanding and using Time Travel](https://docs.snowflake.com/en/user-guide/data-time-travel)
- [Cloning considerations](https://docs.snowflake.com/en/user-guide/object-clone)
- [About Secure Data Sharing](https://docs.snowflake.com/en/user-guide/data-sharing-intro)
- [Apache Iceberg tables](https://docs.snowflake.com/en/user-guide/tables-iceberg)
- [Snowflake pricing calculator](https://www.snowflake.com/en/pricing-options/calculator/)
- [Estimate and control costs](https://cloud.google.com/bigquery/docs/best-practices-costs)
- [Working with resource monitors](https://docs.snowflake.com/en/user-guide/resource-monitors)
- [Snowpark API](https://docs.snowflake.com/en/developer-guide/snowpark/index)
- [Understanding and viewing Fail-safe](https://docs.snowflake.com/en/user-guide/data-failsafe)
- [BigQuery overview](https://cloud.google.com/bigquery/docs/introduction)
- [BigQuery pricing](https://cloud.google.com/bigquery/pricing)
- [Understand slots](https://cloud.google.com/bigquery/docs/slots)
- [Introduction to BigQuery editions](https://cloud.google.com/bigquery/docs/editions-intro)
- [Introduction to partitioned tables](https://cloud.google.com/bigquery/docs/partitioned-tables)
- [Introduction to clustered tables](https://cloud.google.com/bigquery/docs/clustered-tables)
- [Data retention with time travel and fail-safe](https://cloud.google.com/bigquery/docs/time-travel)
- [Introduction to table clones](https://cloud.google.com/bigquery/docs/table-clones-intro)
- [Introduction to BigQuery sharing](https://cloud.google.com/bigquery/docs/analytics-hub-introduction)
- [Introduction to BigQuery ML](https://cloud.google.com/bigquery/docs/bqml-introduction)
- [Apache Iceberg managed tables](https://cloud.google.com/bigquery/docs/iceberg-tables)
- [Subscription overview](https://cloud.google.com/pubsub/docs/subscription-overview)