Redshift vs Snowflake vs BigQuery: A Comparison
Redshift, Snowflake and BigQuery bill for different things: running time, data scanned, capacity-hours. Pricing pages make them hard to compare. This guide prices one realistic workload in each warehouse's own unit, from documented billing rules, and shows the single setting that dominates each bill.
GloryTecks Team
Training & Placement Faculty
Last updated: 10 October 2026
Comparing Redshift vs Snowflake vs BigQuery costs is hard because they do not bill for the same thing. Snowflake charges for the time a warehouse runs, BigQuery's on-demand model charges for the data each query reads, and Redshift Serverless charges for capacity-hours while queries run. Pricing pages list rates; they do not tell you what dominates your bill. The quickest way to understand that is to put one workload through all three billing models.
The billing rules, from the documentation
- Snowflake: warehouses consume credits per hour by size, 1 for X-Small, 4 for Medium, doubling with each size, billed per second with a 60-second minimum each time a warehouse starts or resumes (Snowflake: warehouses).
- BigQuery on-demand: you pay for bytes processed, USD 6.25 per TiB, with the first TiB each month free (Google Cloud: BigQuery pricing).
- Redshift Serverless: capacity used is billed in RPU-hours per second while queries run, with nothing for idle time (AWS: on-demand billing), and a minimum charge of 60 seconds of usage (AWS: Serverless billing).
One workload, three bills
The workload: a 25-minute nightly batch reading 200 GiB, plus 120 interactive dashboard queries a day spread across eight hours, each running 12 seconds and reading 2 GiB, over 22 working days. These are assumptions to replace with your own; the point is the shape of each bill.
# One workload, three billing models. Every input below is an assumption you should replace with your own.
DAYS = 22 # working days a month
ETL_MINUTES = 25 # nightly batch, minutes of compute
ETL_SCAN_GIB = 200 # data the nightly batch reads
QUERIES = 120 # interactive queries per working day, spread over 8 hours
QUERY_SECONDS = 12 # compute time per interactive query
QUERY_SCAN_GIB = 2 # data each interactive query reads
GAP_SECONDS = 8 * 3600 / QUERIES # average gap between queries: 240 seconds
# Snowflake: credits per hour by size (X-Small 1, Medium 4), per-second billing, 60-second minimum per resume
def snowflake(auto_suspend):
etl = 4 * ETL_MINUTES / 60 # Medium warehouse for the batch
if auto_suspend >= GAP_SECONDS: # never idles long enough to suspend
interactive = 1 * 8 # X-Small stays up all 8 hours
else:
per_query = max(60, QUERY_SECONDS + auto_suspend) # runs, idles until suspend; at least 60 s
interactive = 1 * QUERIES * per_query / 3600
return etl + interactive
print("B1 Snowflake credits per working day (Medium for the batch, X-Small for queries)")
for s in (60, 300, 600):
print(f" auto-suspend {s:>3} s: {snowflake(s):5.2f} credits/day | {snowflake(s) * DAYS:6.1f} credits/month")
# BigQuery on-demand: billed by data processed, USD 6.25 per TiB, first 1 TiB per month free
tib = (ETL_SCAN_GIB + QUERIES * QUERY_SCAN_GIB) * DAYS / 1024
print(f"\nB2 BigQuery on-demand: {tib:.2f} TiB processed/month -> USD {max(0, tib - 1) * 6.25:,.2f} after the free TiB")
for pruned in (0.5, 0.1):
t = (ETL_SCAN_GIB + QUERIES * QUERY_SCAN_GIB * pruned) * DAYS / 1024
print(f" if partitioning/clustering cut query scans to {pruned:.0%}: {t:.2f} TiB -> USD {max(0, t - 1) * 6.25:,.2f}")
# Redshift Serverless: RPU-hours billed per second while queries run, 60-second minimum charge
def redshift(rpu, batched):
etl = rpu * ETL_MINUTES / 60
per_query = QUERY_SECONDS if batched else max(60, QUERY_SECONDS) # isolated queries pay the minimum
return etl + rpu * QUERIES * per_query / 3600
print("\nB3 Redshift Serverless RPU-hours per working day at an assumed 32 RPU")
print(f" each query billed alone (60 s minimum each): {redshift(32, False):6.1f} RPU-hours/day | {redshift(32, False) * DAYS:7.1f}/month")
print(f" queries overlapping, billed for run time: {redshift(32, True):6.1f} RPU-hours/day | {redshift(32, True) * DAYS:7.1f}/month")B1 Snowflake credits per working day (Medium for the batch, X-Small for queries)
auto-suspend 60 s: 4.07 credits/day | 89.5 credits/month
auto-suspend 300 s: 9.67 credits/day | 212.7 credits/month
auto-suspend 600 s: 9.67 credits/day | 212.7 credits/month
B2 BigQuery on-demand: 9.45 TiB processed/month -> USD 52.83 after the free TiB
if partitioning/clustering cut query scans to 50%: 6.88 TiB -> USD 36.72
if partitioning/clustering cut query scans to 10%: 4.81 TiB -> USD 23.83
B3 Redshift Serverless RPU-hours per working day at an assumed 32 RPU
each query billed alone (60 s minimum each): 77.3 RPU-hours/day | 1701.3/month
queries overlapping, billed for run time: 26.1 RPU-hours/day | 574.9/monthWhat dominates each bill
Snowflake: idle time. With auto-suspend at 60 seconds, the small query warehouse ran for each query plus a minute of idle time: about 4.1 credits a day, 89.5 a month. With auto-suspend at 300 seconds, longer than the four-minute gap between queries, the warehouse never suspended and stayed up all eight hours: 9.7 credits a day, 212.7 a month, more than double for the same queries. Setting auto-suspend to 600 seconds changed nothing further. Auto-suspend and warehouse size are the main levers; query speed matters less than how long the warehouse sits idle.
BigQuery: data scanned. The workload processed about 9.45 TiB a month, about USD 52.83 after the free TiB. Running time did not matter at all. If partitioning and clustering cut the interactive queries' scans to half, the cost fell to USD 36.72; to a tenth, USD 23.83. In BigQuery on-demand, table design is cost control.
Redshift Serverless: short isolated queries. At an assumed 32 RPU, if every 12-second query were billed alone at the 60-second minimum, the workload used 77.3 RPU-hours a day. If the queries overlapped, so that capacity was billed for actual run time, it fell to 26.1. Workloads of many short, separate queries pay a premium; base capacity and a maximum RPU-hours limit are the controls.
Comparing across warehouses
The units are not directly comparable: a credit, a TiB and an RPU-hour each have their own price, which varies by edition, region and contract. To compare properly, take your own workload's logs, run them through each model as above, then apply the prices from your quotes. The model also shows where each platform punishes a workload: Snowflake punishes idle warehouses, BigQuery on-demand punishes full-table scans, and Redshift Serverless punishes many tiny isolated queries.
Where the simple model breaks down
The model uses averages, and real workloads are lumpier. Three simplifications matter most.
Arrival pattern. The Snowflake result depends on the gap between queries. The model spreads 120 queries evenly, four minutes apart. Real dashboards arrive in bursts around meetings and refreshes, with long quiet spells in between. Bursty traffic helps a short auto-suspend, because the warehouse sleeps through the quiet spells, and it can also make Redshift queries overlap more, which reduces the minimum-charge penalty.
Concurrency. The model treats each query as running alone on a fixed amount of compute. In practice, a Snowflake warehouse runs several queries at once for the same credits, and Redshift Serverless can scale capacity up for heavy periods, which raises RPU-hours while it lasts.
Caching. All three warehouses reuse cached results in some situations, and a repeated dashboard query may then cost little or nothing. The model ignores this, so for highly repetitive dashboards it overstates cost.
None of these change the main lesson, which billing setting dominates on each platform, but they do change the numbers, which is why your own usage history is the better input.
Feeding the model with your own usage
Each warehouse records what it billed, so you rarely need to guess the inputs. Snowflake reports hourly credit usage per warehouse in the WAREHOUSE_METERING_HISTORY account usage view (Snowflake: warehouse metering history); BigQuery records bytes billed per on-demand job in INFORMATION_SCHEMA.JOBS (BigQuery: JOBS view); Redshift Serverless reports charged RPU-seconds per minute in SYS_SERVERLESS_USAGE, which keeps only seven days of history, so export it regularly (Redshift: SYS_SERVERLESS_USAGE). A month of that history gives you real query counts, run times and scan sizes. Use it to replace the assumptions at the top of the code, then check the model against the bill you actually received before trusting it for a platform you have not used yet.
Cost controls worth setting on day one
- Snowflake: a short auto-suspend on interactive warehouses, separate warehouses for batch and dashboards, and resource monitors.
- BigQuery: partitioned and clustered tables,
require_partition_filteron large tables, and per-user or per-project quotas. - Redshift Serverless: a sensible base capacity and a maximum RPU-hours usage limit, which the documentation describes as per day, week or month.
For architecture differences, see the BigQuery vs Snowflake vs Redshift comparison; for query portability, Snowflake vs BigQuery vs Redshift SQL.
How does Snowflake bill compute?
How does BigQuery on-demand pricing work?
How is Redshift Serverless billed?
Which cloud warehouse is cheapest?
Warehouse design and cost control are part of the Data Engineering course.
Sources
- Overview of warehouses (Snowflake documentation) — Snowflake
- BigQuery pricing (Google Cloud) — Google Cloud
- Billing for on-demand compute capacity (Amazon Redshift documentation) — Amazon Web Services
- Billing for Amazon Redshift Serverless (Amazon Redshift documentation) — Amazon Web Services
- WAREHOUSE_METERING_HISTORY view (Snowflake documentation) — Snowflake
- JOBS view (BigQuery documentation) — Google Cloud
- SYS_SERVERLESS_USAGE (Amazon Redshift documentation) — Amazon Web Services
GloryTecks Team
Training & Placement Faculty
The GloryTecks faculty team mentors learners across Data Science, AI and Data Engineering, with a focus on real-time projects and placement readiness in Hyderabad.
Want to master AWS?
Join GloryTecks’ expert-led Data Engineering training in Hyderabad with real-time projects and 100% placement support.
Related articles
Amazon Redshift Explained: The Cloud Data Warehouse
An introduction to Amazon Redshift, AWS's data warehouse: how a leader node, compute nodes and slices run a query in parallel, why data is stored in columns, how managed storage separates compute from storage, Serverless versus a provisioned cluster, how it differs from PostgreSQL, and what to learn first.
AWS Roadmap 2026 for Data Engineers
What to learn on AWS as a data engineer, in the order data moves through a pipeline: S3 and IAM, Glue and Athena, Glue jobs, Redshift, Step Functions, streaming and governance, with something to build at every stage and a clear test for when you are done.
Amazon S3 Explained: Storage, Classes and Best Practices
How Amazon S3 storage classes differ — minimum storage duration, minimum billable size, retrieval time — and a four-question method for putting each dataset in the right class, with lifecycle and security defaults for a data-engineering bucket.