How to choose a data warehouse: BigQuery, Snowflake, Redshift, Athena and Databricks compared

How to choose a data warehouse in three questions

If you are signing off on a warehouse rather than running it, ask your analyst to answer three questions in writing.

1. Where does the data and the team already live? Data already in Google Cloud points to BigQuery. Data in Amazon S3 and an AWS team point to the AWS data warehouse options, Redshift (Serverless or provisioned) and Athena. An existing Databricks contract points to Databricks SQL. Snowflake’s documentation says “a Snowflake account can be hosted on” AWS, Google Cloud or Microsoft Azure (Snowflake docs, October 2026), which makes it the usual pick when no cloud has won inside the company.
2. What does the meter charge for, and does it match how we query? One meter charges for bytes scanned (BigQuery on-demand, Athena); the other for compute time while something runs (Snowflake credits, Redshift RPU-hours, Databricks DBUs).
3. What cost limit can we set, and does it stop spend or only report it? You want at least one hard stop before the first dashboard goes live.

For marketing and product reporting, SQL dialect, connectors and BI support matter less than the meter: that data storage holds mostly plain tables read by a few dashboards. Still deciding whether you need a warehouse at all? Start with databases vs data warehouses vs data lakes.

Data warehouse comparison matrix: the five side by side

This cloud data warehouse comparison uses only what each vendor states on its own pages, read on 15 October 2026. It holds no prices: rates change by region and contract. Where a vendor states nothing, the cell says so.

Sources, all read 15 October 2026: Google – pricing, introduction, Iceberg tables, cost best practices. Snowflake – compute cost, warehouses, Iceberg tables, resource monitors. AWS Redshift – pricing, Serverless billing, usage limits, Iceberg writes. AWS Athena – pricing, Iceberg, cost controls. Databricks – pricing, SQL warehouses, Iceberg.

Three things in the matrix change the decision more than the rest:

• BigQuery and Athena share a 10 MB floor on demand: per query on Athena, per query and per table referenced on BigQuery.
• Every time-based meter has a floor too. Snowflake’s 1-minute minimum starts over on every resume; Redshift Serverless bills at least 60 seconds.
• The hard stops differ. BigQuery quotas stop queries once reached, Athena cancels a query over its limit, Redshift Serverless can turn off user queries and Snowflake suspends a warehouse. On Databricks, the budget page’s blocking option applies to Unity Gateway, so the control a team sets on a SQL warehouse is Auto Stop.

For deeper two-way comparisons, see Snowflake vs BigQuery, Snowflake pricing and cost control and Databricks pricing.

What the meter does to real queries

Here is what the rules did to queries we ran on Google BigQuery on-demand, using BigQuery’s own processed and billed byte counts. The first run is on owox-demo, a synthetic demo dataset; the second is real: a month of one analytics project’s query log.

A one-month spend report billed 16.7 times what it read

ecommerce.ad_performance is a view that unions seven ad-platform tables (Facebook, Google, TikTok, Microsoft, LinkedIn, Reddit, X) into one spend table. The question a marketing leader asks every month – spend by source for September – looks like this:

SELECT source, SUM(spend) AS spend
FROM `owox-demo.ecommerce.ad_performance`
WHERE date BETWEEN '2026-09-01'
  AND '2026-09-30'
GROUP BY source
ORDER BY spend DESC

The September query read 4.4 MB and was billed 73.4 MB. 73,400,320 is exactly 7 × 10,485,760: seven tables referenced, a 10 MB minimum for each, as Google’s pricing page states. The date filter cut what was read and changed nothing on the bill. Athena’s pricing page states a 10 MB minimum per query; we did not run the query there.

A dashboard that fires many small queries over a view with many source tables pays for the minimums, not for the data. The other half of the bytes meter – how column choice and table layout change what a query reads – is measured in step 5 of the implementation guide.

A real month of one project’s queries under both meters

Whether the floor matters depends on the whole workload, so we took a real one: the BigQuery job log of one OWOX analytics project, 15 September to 14 October 2026, successful SELECT jobs only. Not demo data: an AI assistant, scheduled service accounts and a person all queried it. The first query summarises it under the meter it was billed on:

WITH jobs AS (
  SELECT
    total_bytes_processed AS read_b,
    total_bytes_billed AS billed_b,
    cache_hit,
    TIMESTAMP_DIFF(end_time, start_time,
      MILLISECOND) AS ms
  FROM `region-us`.INFORMATION_SCHEMA
    .JOBS_BY_PROJECT
  WHERE creation_time >= '2026-09-15'
    AND creation_time < '2026-10-15'
    AND job_type = 'QUERY'
    AND statement_type = 'SELECT'
    AND state = 'DONE'
    AND error_result IS NULL
)
SELECT
  COUNT(*) AS jobs,
  COUNTIF(billed_b > 0) AS billed_jobs,
  COUNTIF(cache_hit) AS cache_hits,
  ROUND(SUM(read_b) / 1e9, 1) AS gb_read,
  ROUND(SUM(billed_b) / 1e9, 1) AS gb_billed,
  COUNTIF(billed_b > 0
    AND billed_b > 2 * read_b) AS over_2x,
  COUNTIF(billed_b = 10485760) AS at_floor,
  COUNTIF(billed_b > 0
    AND read_b < 10485760) AS read_lt_10mb,
  APPROX_QUANTILES(ms, 100)[OFFSET(50)]
    AS p50_ms,
  APPROX_QUANTILES(ms, 100)[OFFSET(90)]
    AS p90_ms,
  COUNTIF(ms < 60000) AS under_60s,
  ROUND(SUM(ms) / 1000, 1) AS runtime_s
FROM jobs

Half the billed jobs paid more than twice what they read, yet the floors added only 5.4% to the month. Who sent the queries explains why. Splitting the same jobs by their label (jobs an AI assistant sends through Google’s BigQuery MCP server carry the label goog-mcp-server) and by user:

SELECT
  CASE
    WHEN EXISTS (SELECT 1 FROM UNNEST(labels)
      WHERE key = 'goog-mcp-server')
      THEN 'AI assistant via MCP'
    WHEN user_email
      LIKE '%gserviceaccount.com'
      THEN 'Service accounts'
    ELSE 'A person, directly'
  END AS who,
  COUNT(*) AS jobs,
  COUNT(DISTINCT user_email) AS users,
  COUNTIF(total_bytes_billed > 0)
    AS billed_jobs,
  ROUND(SUM(total_bytes_processed) / 1e9, 1)
    AS gb_read,
  ROUND(SUM(total_bytes_billed) / 1e9, 1)
    AS gb_billed,
  ROUND(100 * (SUM(total_bytes_billed)
    / SUM(total_bytes_processed) - 1), 1)
    AS floors_pct,
  COUNTIF(total_bytes_billed > 0
    AND total_bytes_billed
      > 2 * total_bytes_processed) AS over_2x
FROM `region-us`.INFORMATION_SCHEMA
  .JOBS_BY_PROJECT
WHERE creation_time >= '2026-09-15'
  AND creation_time < '2026-10-15'
  AND job_type = 'QUERY'
  AND statement_type = 'SELECT'
  AND state = 'DONE'
  AND error_result IS NULL
GROUP BY who
ORDER BY jobs DESC

The floors are an exploration cost. The assistant’s many small probe and metadata queries paid 9.3% on top of what they read; the person’s mostly large reads paid 0.2%. A team that puts AI agents on a bytes-metered warehouse should expect the floors to matter.

The second query asks what the same month would cost on a time-based meter. It is a model, not a measurement: it replays the real start and end times against the rules Snowflake and Redshift Serverless state – per-second billing with a 60-second minimum that restarts on every resume – and an auto-suspend setting of 60 or 600 seconds. Jobs that start before the previous ones have finished plus the idle setting share one busy window; each window bills its length plus the idle tail, at least 60 seconds. It assumes one compute unit and BigQuery’s own runtimes; another engine would run the same queries faster or slower.

WITH jobs AS (
  SELECT start_time, end_time
  FROM `region-us`.INFORMATION_SCHEMA
    .JOBS_BY_PROJECT
  WHERE creation_time >= '2026-09-15'
    AND creation_time < '2026-10-15'
    AND job_type = 'QUERY'
    AND statement_type = 'SELECT'
    AND state = 'DONE'
    AND error_result IS NULL
),
idle AS (SELECT n FROM UNNEST([60, 600]) AS n),
marked AS (
  SELECT n, start_time, end_time,
    IF(TIMESTAMP_DIFF(start_time,
      MAX(end_time) OVER (
        PARTITION BY n ORDER BY start_time
        ROWS BETWEEN UNBOUNDED PRECEDING
          AND 1 PRECEDING),
      MILLISECOND) < n * 1000, 0, 1) AS new_win
  FROM jobs CROSS JOIN idle
),
numbered AS (
  SELECT *, SUM(new_win) OVER (
    PARTITION BY n ORDER BY start_time) AS w
  FROM marked
),
windows AS (
  SELECT n, w,
    TIMESTAMP_DIFF(MAX(end_time),
      MIN(start_time), MILLISECOND) / 1000
      AS busy_s
  FROM numbered
  GROUP BY n, w
)
SELECT n AS auto_suspend_s,
  COUNT(*) AS resumes,
  ROUND(SUM(GREATEST(busy_s + n, 60))
    / 3600, 2) AS billed_hours
FROM windows
GROUP BY n
ORDER BY n

On the bytes meter, the floors added 5.4%. On a time meter, the idle tails would be billed 10.8 to 57.7 times the query runtime, depending on one setting. The two are different units – extra bytes over bytes read, idle hours over runtime – and neither is a price. They show where each meter’s waste comes from: short queries with gaps between them feed a time meter mostly idle minutes.

The decision rule

Match the meter to your query pattern, not to a benchmark. Before signing, have your analyst run the two queries above on your own job log. If the floors add a few percent and the busy windows are mostly idle, a bytes meter fits. If the windows are nearly full, a time meter with a short auto-suspend fits. That is your data warehouse cost comparison, on your own workload.

Which data warehouse fits which team

The same warehouse can work well for one team and badly for another. What decides it is who will run it and what they will run on it in the next 12–24 months:

So what is the best data warehouse for product analytics? The one where your event data already lands, with tables laid out by date. On Google’s public GA4 sample, the same one-day question read 0.34 MB or 99 MB depending on layout alone (step 5 of the implementation guide linked above); no vendor choice recovers that.

Internal dashboards plus an external analytics feature, with workload isolation. Put the two on separate compute with separate limits. Snowflake’s documentation says each virtual warehouse is an independent compute cluster. On Athena, workgroups carry their own data-scanned limits; on Redshift Serverless and BigQuery, check how usage limits and reservations split by workload before you commit.

Data warehouse vs a serverless query engine for ad-hoc analytics on object storage. For occasional questions over files in S3, a serverless engine such as Athena queries them in place with no infrastructure to set up, per AWS’s documentation. Once the same queries feed daily dashboards, per-query minimums and scan charges add up, and a warehouse or shared Iceberg tables become the better deal. AWS Athena explained and data lakehouse architecture go deeper on both paths.

The warehouse stores the numbers; the model makes them trustworthy

None of the five platforms knows that your spend feed stopped. On our demo data, every row-level check passed while ad spend ended five days before orders, so that week’s ROAS divided revenue by zero spend (step 7 of the implementation guide). That is the head of marketing’s problem from the opening, and no warehouse choice fixes it. It is fixed by a data model: agreed definitions of spend, orders and revenue, each owned by someone, with checks on every Data Mart run before the number reaches a slide.

OWOX Data Marts builds that layer on the warehouse you choose. It runs on all five storages compared here – Google BigQuery, Snowflake, AWS Redshift, AWS Athena and Databricks – so the warehouse decision and the trust decision stay separate. An analyst defines each Data Mart in SQL, with a description, an owner and its relationships to other Data Marts, and reports are built on those definitions rather than on raw tables. How to build a governed Data Mart library shows where to start: with the numbers people already argue about. You can try it on your own warehouse at OWOX Data Marts.

Data QualityWhat is data freshness? How to measure it and how fresh a decision needsOctober 14, 2026→Data AnalyticsDatabase vs data warehouse vs data lake: what each one is for and where your data belongsOctober 15, 2026→Data AnalyticsData lakehouse use cases: real examples and when you need oneOctober 15, 2026→

See all articles →