Snowflake vs BigQuery vs Redshift: How to Compare Them

Snowflake, Google BigQuery and Amazon Redshift are the three cloud data warehouses that come up most often in Data Engineer job descriptions. All three store data in columns, run SQL in parallel, separate storage from compute (at least on their modern options), read open table formats and offer row and column security. What differs is the operating model: who sizes the compute, how you are billed, which physical design levers you pull, and how tightly each is tied to one cloud.

This page gives you a neutral framework for the comparison. It does not repeat the Snowflake versus Databricks material, which is in Snowflake vs Databricks, or the general warehouse and lakehouse trade-offs in Lake vs warehouse vs lakehouse.

Architecture

Snowflake has three layers: storage, compute and cloud services. Table data is stored once, in compressed columnar micro-partitions, in object storage on whichever cloud hosts the account (AWS, Azure or Google Cloud). Compute is virtual warehouses: clusters you size in T-shirt sizes, which suspend and resume and can all read the same data. The services layer handles metadata, optimisation, transactions and security. You provision warehouses, but you never manage nodes, files or vacuuming. The details are in Snowflake architecture.

BigQuery is serverless. You create datasets and tables and run queries; BigQuery decides how many slots (virtual compute units) each query stage uses, and you cannot set that per query. Storage and compute are separate services, which is also what lets BigQuery share datasets without copying them. You choose a billing model for compute (on-demand or capacity, covered below), not a cluster size.

Redshift comes in two deployment options:

• Provisioned clusters: a leader node that plans queries and compute nodes that run them. With RA3 node types (and the newer Graviton-based RG node types), table data lives in Redshift Managed Storage: local SSDs act as a cache and Amazon S3 holds the durable copy, so compute and storage are sized and billed independently. The older DC2 nodes keep data on local SSDs, so adding storage means adding nodes.
• Redshift Serverless: no clusters to manage. A workgroup has a base capacity in Redshift Processing Units (RPUs) and scales up from it under load. AWS also offers AI-driven scaling and optimization, where you set a price-performance target and Serverless adjusts capacity to meet it.

	Snowflake	BigQuery	Redshift
Storage and compute	Separate	Separate	Separate on RA3, RG and Serverless; coupled on DC2
Compute you size	Virtual warehouses (sizes, multi-cluster)	Nothing per query; optional slot reservations	Nodes (provisioned) or base and maximum RPUs (Serverless)
Serverless option	Serverless features (Snowpipe, Automatic Clustering, serverless tasks and others) alongside warehouses	The whole service	Redshift Serverless
Clouds	AWS, Azure, Google Cloud	Google Cloud; BigQuery Omni queries data in AWS and Azure (Enterprise edition or on-demand)	AWS only

Pricing models

Never compare these warehouses by headline unit price. The units measure different things, and every vendor’s rate depends on edition, region and commitment. Compare the shape of each model, then measure your own workloads. Current rates are on the Snowflake pricing page, the BigQuery pricing page and the Amazon Redshift pricing page.

Snowflake: credits. A running warehouse consumes credits at a rate set by its size. Billing is per second, with a 60-second minimum each time a warehouse starts or resumes. Serverless features consume credits on their own meters, and storage is billed per compressed terabyte per month (Time Travel and Fail-safe retention add to it). The price of a credit depends on edition, region and contract. What drives the bill is warehouses left running and oversized warehouses; see Snowflake cost optimization.

BigQuery: on-demand or capacity.

• On-demand (the default) charges for the bytes each query processes, per TiB. Because storage is columnar, you pay for the columns a query reads, so SELECT * on a wide table is expensive, and on a non-clustered table LIMIT does not reduce the bytes read. Cached results and failed queries are not charged. A project on on-demand gets a shared pool of slots, generally up to about 2,000 concurrent slots.
• Capacity pricing charges for slots over time (slot-hours) through reservations in one of three editions: Standard, Enterprise and Enterprise Plus. Reservations can have always-on baseline slots, autoscaling slots up to a maximum, and optional one- or three-year commitments on Enterprise and Enterprise Plus. Autoscaled capacity is billed per second with a one-minute minimum by default.
• You can mix the two models across projects. Storage is billed separately, with a lower long-term rate for tables or partitions not modified for 90 consecutive days, and a choice of logical (uncompressed) or physical (compressed) storage billing, set per dataset.

Redshift: nodes or RPUs.

• Provisioned cost depends on node type, node count and region, with discounts for reserved nodes. On RA3 and RG you pay for managed storage separately. Features such as concurrency scaling and Spectrum queries on S3 (for RA3 clusters) have their own charges.
• Serverless bills RPU-hours per second, with a 60-second minimum, for both base and scaled capacity; storage is billed separately per GB-month. You can buy Serverless reservations for steady use, and you should set a maximum RPU-hours limit so a busy month cannot surprise you.

The trap in every model is the same: idle or oversized compute. On BigQuery on-demand it is the other way round: badly filtered queries cost money even if they finish quickly.

Performance tuning levers

All three skip data using metadata (minimum and maximum values per block or micro-partition). The levers you control decide how well that skipping works, and on Redshift also where rows sit for joins.

	Snowflake	BigQuery	Redshift
Main lever	Clustering key (CLUSTER BY) on large tables	PARTITION BY (time-unit column, ingestion time or integer range) plus CLUSTER BY up to four columns	Sort key (compound or interleaved, or AUTO) and distribution style (AUTO, EVEN, KEY, ALL)
Who maintains it	Automatic Clustering, a serverless service billed in credits	Automatic reclustering in the background at no charge	AUTO keys and automatic table sort; VACUUM and ANALYZE still matter for heavily changed tables
Cost guardrail	Warehouse size and auto-suspend	require_partition_filter, dry-run cost estimates, maximum bytes billed, custom daily query quotas	WLM queues, Serverless maximum RPU-hours
Other accelerators	Result cache, search optimization, query acceleration, materialized views	Cached results, BI Engine, materialized views, search indexes	Materialized views, concurrency scaling

Three differences come up in interviews:

• Snowflake asks you for the fewest physical decisions. Micro-partitioning is automatic; a clustering key is only worth it on large, frequently filtered tables, because reclustering consumes credits. See micro-partitions, clustering and pruning.
• BigQuery partitioning gives an accurate cost estimate before the query runs; clustering alone does not, because the number of blocks scanned is known only afterwards. Partition on the date column most queries filter by, then cluster by the next most common filters, in that order.
• Redshift is the only one of the three where you think about co-locating join keys. A KEY distribution on the join column of two large tables avoids redistributing rows at query time; ALL copies a small dimension to every node. With AUTO (the default), Redshift chooses and can change the style as the table grows. Details are in Redshift distribution styles and sort keys.

The same table and query on each platform

Here is one fact table, tuned the idiomatic way on each warehouse, and one query that benefits. The tables use only syntax shown in each vendor’s CREATE TABLE documentation.

-- Snowflake: cluster a large table by the columns most queries filter on.
CREATE OR REPLACE TABLE orders (
  order_id    NUMBER,
  customer_id NUMBER,
  order_date  DATE,
  amount      NUMBER(12, 2)
)
CLUSTER BY (order_date, customer_id);

-- BigQuery: partition by day on the date column, then cluster within each partition.
CREATE TABLE sales.orders (
  order_id    INT64,
  customer_id INT64,
  order_date  DATE,
  amount      NUMERIC
)
PARTITION BY order_date
CLUSTER BY customer_id
OPTIONS (require_partition_filter = TRUE);

-- Redshift: distribute on the join key, sort on the filter column.
CREATE TABLE sales.orders (
  order_id    BIGINT,
  customer_id BIGINT,
  order_date  DATE,
  amount      DECIMAL(12, 2)
)
DISTSTYLE KEY
DISTKEY (customer_id)
COMPOUND SORTKEY (order_date);

These blocks need a Snowflake account, a Google Cloud project and a Redshift cluster or workgroup, so they were checked against each vendor’s documentation rather than run.

-- The same query runs unchanged on all three (in Snowflake, drop the "sales." schema prefix
-- or create the table in a SALES schema).
SELECT customer_id, SUM(amount) AS revenue
FROM sales.orders
WHERE order_date >= '2026-09-01' AND order_date < '2026-10-01'
GROUP BY customer_id
ORDER BY revenue DESC
LIMIT 10;

What the date filter does on each:

• Snowflake prunes micro-partitions whose order_date range falls outside September. The clustering key keeps those ranges narrow as the table grows.
• BigQuery reads only the September partitions, so the cost estimate covers about one month of the customer_id, order_date and amount columns. Without a date filter, the query is rejected because of require_partition_filter. The LIMIT 10 applies after the aggregation, so it does not reduce the bytes read.
• Redshift skips blocks using zone maps on the sorted order_date column. If the query joined to a customers table also distributed on customer_id, the join would run without moving rows between nodes.

Concurrency

• Snowflake isolates workloads by giving each its own warehouse (ELT, BI, data science). For many simultaneous BI users, a multi-cluster warehouse (Enterprise Edition or higher) adds clusters when queries start to queue and removes them when load drops. See warehouse scaling and concurrency.
• BigQuery shares slots fairly: within a reservation, slots are divided between projects with running queries and then between jobs in each project, and work queues when demand exceeds the slots available. You isolate workloads with separate reservations, for example one for ETL and one for dashboards, and idle baseline slots can be borrowed by other reservations of the same edition in the same administration project. On-demand projects share their slot pool.
• Redshift provisioned manages concurrency with workload management (WLM) queues and concurrency scaling, which adds temporary cluster capacity for bursts of read queries and common write operations such as ETL statements. Redshift Serverless scales RPUs above the base capacity instead. See WLM and concurrency scaling.

Semi-structured data

Snowflake	BigQuery	Redshift
VARIANT, OBJECT and ARRAY types; path notation (v:customer.id) and FLATTEN	Native nested and repeated columns (STRUCT and ARRAY) and a JSON type	SUPER type queried with PartiQL; materialized views can shred it into columns

The practical difference: BigQuery encourages you to keep nested, repeated data in the table design itself, which avoids joins; Snowflake and Redshift load JSON into a flexible type and you extract hot fields into typed columns for performance. Snowflake’s side is covered in table types and semi-structured data.

Open table formats and Iceberg

All three now read and write Apache Iceberg, which matters if you want other engines to use the same data without copying it. The question to answer in a design is still which catalog owns each table.

• Snowflake: Iceberg tables keep Parquet data and Iceberg metadata in your bucket through an external volume. With Snowflake as the catalog, Snowflake manages writes and maintenance and other engines can read the tables. With an external catalog (AWS Glue, Snowflake Open Catalog or another Iceberg REST catalog), Snowflake reads the tables and can also write to tables in REST catalogs, including through a catalog-linked database.
• BigQuery: Apache Iceberg managed tables (formerly BigLake tables for Apache Iceberg in BigQuery) store Parquet files in your Cloud Storage bucket while BigQuery handles DML, streaming, compaction, clustering and garbage collection. BigQuery exports Iceberg metadata so engines such as Spark can read the files. Do not write to those files from outside BigQuery: untracked files are garbage collected. Managed Iceberg tables also have limits that standard tables do not, such as no row-level security.
• Redshift: queries Iceberg tables registered in the AWS Glue Data Catalog (on RA3 through Spectrum, on RG and Serverless on its own compute) and can create and write Iceberg tables in Amazon S3 and S3 table buckets with CREATE TABLE ... USING ICEBERG, INSERT, DELETE, UPDATE and MERGE (writing to Iceberg tables).

The native table format of each warehouse remains proprietary and is not readable as files by other engines. For background on Iceberg, Delta and Hudi, see Delta vs Iceberg vs Hudi.

Governance and security

	Snowflake	BigQuery	Redshift
Access model	Role-based access control inside Snowflake; roles granted to users and other roles	Google Cloud IAM roles on projects, datasets and tables	Database users and role-based access control (RBAC); IAM roles for access to S3 and other AWS services
Row and column controls	Row access policies, masking policies, tag-based masking (Enterprise Edition or higher)	Row-level security, column-level access control, dynamic data masking (Enterprise and Enterprise Plus editions or on-demand)	Row-level security and dynamic data masking policies
Lake governance	Policies on Iceberg tables; Horizon catalog	Policies on Iceberg managed tables (column-level only)	AWS Lake Formation fine-grained permissions on data lake tables
Network and keys	Private connectivity options depend on edition	VPC Service Controls and CMEK (not on Standard edition)	Clusters and workgroups run in your VPC

The useful observation: BigQuery and Redshift govern through their cloud’s identity system (Google Cloud IAM, AWS IAM and Lake Formation), which is convenient if the rest of your platform lives in that cloud. Snowflake keeps its own role model, which is the same on every cloud it runs on. Read Snowflake security and access control and Lake Formation for the details.

Data sharing

• Snowflake Secure Data Sharing shares live tables with other Snowflake accounts without copying data; consumers pay for their own compute. Reader accounts serve consumers without a Snowflake account, and listings on the Snowflake Marketplace reach external buyers. Sharing across regions or clouds requires replication. See Snowflake data sharing.
• BigQuery sharing (formerly Analytics Hub) publishes datasets as listings in data exchanges; subscribers get a read-only linked dataset in their own project, with no copy, and pay for their own queries. Publishers can restrict exports from linked datasets.
• Redshift data sharing shares live data across clusters, Serverless workgroups, AWS accounts and AWS Regions, for both reads and writes. Data products can be listed in AWS Data Exchange.

All three avoid copying data inside their own platform. Sharing across platforms (Snowflake to BigQuery, for example) means open tables in a shared bucket, exports, or a replication tool.

Comparison at a glance

Dimension	Snowflake	BigQuery	Redshift
Operating model	Managed warehouse; you size and schedule warehouses	Serverless; optional slot reservations	Provisioned clusters or Serverless
Compute billing	Credits per second (60-second minimum)	Per TiB processed, or slot-hours by edition	Node-hours, or RPU-hours per second (60-second minimum)
Main tuning DDL	CLUSTER BY	PARTITION BY plus CLUSTER BY	DISTSTYLE, DISTKEY, SORTKEY
Concurrency	Separate warehouses; multi-cluster warehouses	Fair scheduling of slots; reservations per workload	WLM and concurrency scaling; Serverless RPU scaling
Semi-structured	VARIANT	Nested STRUCT and ARRAY, JSON	SUPER with PartiQL
Iceberg	Read and write (Snowflake or external REST catalog)	Iceberg managed tables in your bucket	Read and write through AWS Glue Data Catalog
Clouds	AWS, Azure, Google Cloud	Google Cloud (Omni for AWS and Azure)	AWS
Sharing	Secure Data Sharing, Marketplace	BigQuery sharing, linked datasets	Data sharing, AWS Data Exchange

When to choose each

If your situation is mostly…	Leaning	Why
Multi-cloud or cloud-neutral strategy; many teams with separate compute budgets; SQL and dbt ELT	Snowflake	Same product on three clouds; warehouses give simple workload isolation and chargeback
Platform already on Google Cloud; spiky or unpredictable ad hoc analysis; small platform team	BigQuery	Nothing to size; on-demand suits irregular use, reservations suit steady use
Platform already on AWS; data lake on S3 with Glue and Lake Formation; steady, well-understood workloads	Redshift	Tight AWS integration; Serverless for variable load, provisioned RA3 or RG for steady load with reservations
Need open tables that several engines read	Any of the three, designed deliberately	All write Iceberg now; choose the owning catalog first
Existing estate and skills strongly on one side	The existing one	Migration and retraining usually cost more than the feature differences

Two honest caveats. First, the cloud you already run on usually decides more than the warehouse features do: egress costs, identity, networking and procurement all favour staying in one cloud. Second, each warehouse can be made cheap or expensive by how you use it, so a proof of concept on your own workloads beats any published benchmark.

How to run a fair evaluation

1. Pick three to five real workloads: a large nightly transformation, a dashboard query set under concurrency, an incremental load, and an ad hoc exploration pattern.
2. Implement each idiomatically: clustering keys on Snowflake, partitioning and clustering on BigQuery, distribution and sort keys on Redshift. Do not port one platform’s design unchanged.
3. Measure runtime, total cost (including serverless meters, storage, Spectrum or data lake scans and concurrency scaling), and the operational work: sizing, monitoring, failure recovery.
4. Test both billing models where they exist: BigQuery on-demand against a reservation, and Redshift Serverless against provisioned capacity.
5. Check governance against your requirements: row and column security, auditing, and how each fits your identity provider.

Common mistakes

1. Comparing a credit, a TiB scanned and an RPU-hour as if they were the same unit.
2. Running SELECT * or unfiltered queries on BigQuery on-demand and being surprised by the bill; on non-clustered tables LIMIT does not help, while partition filters, column selection and maximum bytes billed do.
3. Leaving Snowflake warehouses or Redshift provisioned clusters running all night with nothing to do.
4. Adding clustering keys to small Snowflake tables, or partitioning BigQuery tables into many tiny partitions.
5. Choosing KEY distribution on a skewed column in Redshift, so one slice does most of the work.
6. Letting two engines write the same Iceberg table through different catalogs.
7. Repeating out-of-date claims such as “Redshift cannot scale storage separately from compute” (RA3, RG and Serverless can) or “BigQuery has no fixed-cost option” (capacity reservations exist).

In an interview

If asked “Snowflake, BigQuery or Redshift?”, start with the context (which cloud, workload shape, team skills, governance needs), then map it to each platform’s operating model and billing model, and end with a recommendation for the scenario stated. A strong shape: “We are on AWS with a Glue-catalogued S3 lake and steady nightly ELT, so I would start with Redshift and compare Serverless against RA3 with reservations; if the company were multi-cloud I would look at Snowflake, and if it were on Google Cloud with irregular analyst queries, BigQuery on-demand with partition filters required.” Expect follow-ups on the tuning levers (clustering keys, partitioning and clustering, distribution and sort keys), on cost control, and on Iceberg interoperability. Practise with the Redshift distribution and sort keys question and when to use clustering keys in Snowflake.

Key takeaway

All three are mature, columnar, separated-storage warehouses that read and write Iceberg. Snowflake gives you sized warehouses on any of three clouds, BigQuery gives you serverless compute billed by data scanned or by slots, and Redshift gives you AWS-native provisioned or serverless capacity with distribution and sort keys to tune. Decide by your cloud, your workload shape and measured cost, not by headline prices.