Snowflake vs BigQuery vs Redshift: Cost Per Query (2026)

Before any dollar math makes sense, you need to know what unit each vendor is actually metering. This is the part people skip, and it's why "which warehouse is cheaper" is the wrong first question.

• BigQuery on-demand meters bytes scanned by the query, independent of how long it takes or how much compute BigQuery throws at it behind the scenes. A query that touches 10 GB costs the same whether it finishes in 200ms or 20 seconds. There is also a flat-rate/editions alternative (Standard, Enterprise, Enterprise Plus) that bills for reserved slots — compute capacity — instead of bytes, which we cover below.
• Snowflake meters warehouse compute time, billed in credits. A warehouse is a cluster you size (X-Small up to 6X-Large), it burns credits per second while running, and it auto-suspends when idle. Bytes scanned don't directly appear on the bill at all — a query that scans 1 GB and a query that scans 1 TB cost the same if they both take 10 seconds on the same warehouse size. What you pay for is wall-clock time on a given warehouse size.
• Redshift has two distinct models. RA3 provisioned clusters bill per node-hour (on-demand or reserved), so your cluster cost is fixed regardless of query count — you're paying for a running cluster, and query cost is really just that fixed cost divided by however many queries you ran. Redshift Serverless instead bills per RPU-second (Redshift Processing Unit), scaling compute up and down automatically and charging only while a query is actually running.

Three different meters — bytes, time-on-a-cluster, and elastic-compute-seconds — means a fair comparison requires picking a representative query and running each one's formula against it, which is what the next three sections do.

BigQuery on-demand pricing is approximately $6.25 per TB scanned at current public list pricing (this has moved before and will move again — check the BigQuery pricing page for the live number). The first 1 TB scanned per month is typically included free. There is no charge for query time itself, storage is billed separately, and cached queries that hit BigQuery's result cache are free.

Worked examples, assuming a query scans 1 TB and a smaller query scans 100 GB:

• 1 TB scan: 1 TB × $6.25/TB = $6.25 per query
• 100 GB scan: 0.1 TB × $6.25/TB = $0.625 per query
• 1 GB scan (a well-filtered, partition-pruned query): 0.001 TB × $6.25/TB = $0.00625 per query

The lever is obvious once you see the formula: cost is purely a function of bytes scanned, so a query that reads a well-partitioned slice of a table can cost 1,000x less than one that scans the whole thing, with zero change in what the query returns.

The alternative to on-demand is flat-rate pricing via BigQuery editions (Standard, Enterprise, Enterprise Plus), where you buy a pool of slots — fixed parallel query-processing capacity — on an hourly, monthly, or annual commitment, and bytes scanned stop mattering entirely. Editions pricing is a flat $/slot-hour regardless of how many bytes any individual query touches. Flat-rate wins over on-demand when you run a high , steady volume of large-scan queries: at some scan volume the on-demand bill (which scales linearly with bytes) crosses above what a fixed slot commitment would cost, and past that crossover, flat-rate is strictly cheaper. Teams running dashboards or ETL that scan terabytes continuously throughout the day are the classic case; a team running a handful of ad hoc analyst queries a day is the classic case for staying on-demand.

Snowflake warehouses come in T-shirt sizes, and each size doubles the credit burn rate of the one below it: X-Small = 1 credit/hour, Small = 2, Medium = 4, Large = 8, X-Large = 16, and so on up to 6X-Large at 512. You pay for whichever size warehouse you run, for however long it is active, billed by the second (with a typical 60-second minimum per resume).

The price of a credit depends heavily on cloud (AWS/Azure/GCP), region, and Snowflake edition (Standard, Enterprise, Business Critical) — publicly, credits run roughly in the $2–$4 per credit range on standard contracts, though negotiated enterprise deals can land outside that band in either direction. Use your own contract rate for anything beyond ballpark planning.

Worked example: assume a Medium warehouse (4 credits/hour) at $3/credit, running a representative analytical query that takes 30 seconds to complete.

• Cost per hour of Medium warehouse time: 4 credits × $3/credit = $12/hour
• Cost per second: $12 / 3,600 seconds = $0.00333/second
• 30-second query: 30 × $0.00333 = ~$0.10 per query

At $2/credit instead of $3, that same query drops to roughly $0.067; at a faster 10-second query on the same warehouse it drops to roughly $0.022–$0.033. The critical thing to notice: this number has nothing to do with whether the query scanned 1 GB or 1 TB. Two queries with wildly different data volumes but the same runtime cost the same on Snowflake, which is the opposite of how BigQuery on-demand behaves. That also means Snowflake's biggest cost-per-query lever is runtime, not bytes — auto-suspend settings, warehouse sizing, and query tuning that shortens wall-clock time all move the number directly.

Redshift RA3 provisioned clusters bill by the node-hour, on-demand or reserved (1-year and 3-year reservations discount the on-demand rate meaningfully). A representative on-demand ra3.xlplus node runs on the order of $1–$3/hour depending on region, and a small production cluster is commonly 2–4 nodes. That cost is fixed once the cluster is running — it doesn't change whether you run 10 queries an hour or 1,000.

Worked example: a 2-node ra3.xlplus cluster at ~$1.30/node-hour on-demand costs $2.60/hour regardless of query count.

• At 500 queries/hour: $2.60 / 500 = ~$0.0052 per query
• At 50 queries/hour: $2.60 / 50 = ~$0.052 per query
• At 5 queries/hour (idle cluster, low traffic): $2.60 / 5 = ~$0.52 per query

This is the defining property of any node-hour/capacity model: cost per query falls as query volume rises, because you're dividing a fixed hourly cost across more work. It also means an idle or lightly-used RA3 cluster is the most expensive way to run a handful of queries, because you're paying for capacity nobody is using.

Redshift Serverless instead bills per RPU-second — representative public list pricing is roughly $0.36–$0.375 per RPU-hour, i.e. about $0.0001/RPU-second, with a base capacity you configure (commonly starting around 8 or 32 RPU) that scales up automatically under load. Worked example: assume a 32 RPU workgroup running a representative query for 30 seconds, with $0.375/RPU-hour.

• Cost per RPU-second: $0.375 / 3,600 = $0.0001042
• Cost per second at 32 RPU: 32 × $0.0001042 = $0.00333/second
• 30-second query at 32 RPU: 30 × $0.00333 = ~$0.10 per query

Notice this lands in a similar range to the Snowflake Medium-warehouse example above — that's not a coincidence, it's because both are elastic-compute-time models with comparable capacity units, and both charge for wall-clock runtime rather than bytes touched. The difference from RA3 is that Serverless scales to zero when idle (no query, no charge) rather than billing a fixed hourly cluster cost, which mirrors BigQuery on-demand's "pay only when you query" behavior even though the metered unit (RPU-seconds vs. bytes) is different.

Cost model, what you're actually paying for, and a representative cost-per-query figure for the shared workload assumption used throughout this guide: a query that scans roughly 1 TB of data and, where runtime matters, takes about 30 seconds to complete on mid-sized compute. Treat every dollar figure as illustrative, not a quote.

The chart looks like BigQuery loses badly, but that comparison is only fair if the query really does scan a full terabyte. A well-partitioned BigQuery query scanning 1 GB instead costs about $0.006 — cheaper than any of the capacity-model numbers. The honest takeaway is that BigQuery's cost is a direct function of how much data your queries touch, while Snowflake and Redshift's cost is a function of how long your compute runs and how busy it stays. Neither is universally cheaper; they reward different engineering discipline.

• Spiky, unpredictable query volume → BigQuery on-demand or Redshift Serverless. Both scale to zero when nobody is querying, so you never pay for idle capacity — ideal for analyst-driven or ad hoc workloads with long gaps between queries.
• Steady, high-frequency query volume → Snowflake with a well-sized warehouse, Redshift RA3 reserved, or BigQuery editions. When compute is busy nearly all the time, a fixed-capacity model amortizes its cost across far more queries and beats pay-per-scan or pay-per-second pricing.
• Large full-table scans run routinely (heavy ETL, BI dashboards refreshing constantly) → capacity/flat-rate models (Snowflake, RA3, BigQuery editions) tend to win, because bytes-scanned pricing punishes exactly this pattern.
• Mostly small, well-filtered queries → BigQuery on-demand is very hard to beat, since the bill tracks bytes touched and a narrow scan costs fractions of a cent.
• Auto-suspend and auto-scaling behavior matters more than the sticker price. A Snowflake warehouse left without an aggressive auto-suspend timeout burns credits sitting idle; a Redshift RA3 cluster runs 24/7 unless you pause it manually; BigQuery on-demand and Redshift Serverless don't have this failure mode at all, because there's no persistent cluster to forget about.

Regardless of which warehouse you run, the same handful of techniques move the number, just through different mechanisms depending on whether you're paying for bytes or for time:

• Partition and cluster your tables. On BigQuery, partition pruning directly cuts bytes scanned — and bytes scanned is the entire bill. On Snowflake and Redshift, good clustering keys and sort keys mean the engine reads less data to answer a query, which shortens runtime, and runtime is what you're paying for there.
• Stop using SELECT *. Selecting only the columns you need reduces bytes scanned in columnar engines (all three of these are columnar) directly, and it's usually a five-minute fix with no downside.
• Use materialized views and result caching. BigQuery and Redshift both cache identical repeated queries for free; materialized views precompute expensive aggregations so a dashboard hitting the same rollup 500 times a day pays for it once, not 500 times.
• Right-size warehouse/cluster size. A Snowflake Large warehouse isn't automatically faster in a way that saves money — if a query finishes in half the time but the warehouse costs double per hour, cost per query is a wash. Size to the workload, not to "just in case."
• Tune auto-suspend aggressively. On Snowflake, dropping auto-suspend from 10 minutes to 60 seconds can meaningfully cut credit spend for bursty usage patterns, since idle warehouse time is pure waste. On Redshift, pausing an RA3 cluster during off-hours (nights, weekends) has the same effect.
• Use workload management (WLM) and resource monitors. Redshift WLM queues and Snowflake resource monitors let you cap runaway queries and separate expensive batch jobs from cheap interactive ones, so one bad query doesn't inflate the whole cluster bill.

None of this requires switching vendors. Most teams that think they have a "warehouse pricing problem" actually have a query-hygiene problem, and the fix is cheaper than a migration. For the bigger picture of how warehouse spend shows up next to the rest of your cloud bill, our 2026 cloud cost benchmark report has spend-by-category data worth comparing yourself against.