Data warehouse cost: one workload priced on four platforms

TL;DR. Data warehouse cost for one stated workload (5 TB stored, a 2-minute query burst every 15 minutes through the business day, a 1-hour nightly job) comes to about $740 to $3,500 a month at list price on Snowflake, BigQuery editions, Redshift Serverless and Databricks SQL; BigQuery on demand depends on bytes scanned. The hourly prices of the sizes we picked differ by 1.4 times. The idle timeout moves one warehouse's compute bill by 3 times: at the 10-minute default on Snowflake and Databricks SQL, 75% of the billed hours run no query. And the warehouse invoice is about a sixth of what the platform around it costs.

Most "data warehouse cost" pages either list platforms without a price or pitch one vendor. This post prices one workload on four platforms from each vendor's own price list, read on October 27, 2026, with every assumption written down. It is a list-price model, not a measured benchmark: no query ran. What it shows is which assumptions move the bill, so you know what to measure on your own account first.

A data warehouse bill has three lines, and the platform has three more

Every cloud warehouse bills compute, storage and data transfer. The compute unit is where they differ:

Sources: Snowflake's Service Consumption Table (effective October 15, 2026), BigQuery pricing, AWS's Redshift and S3 price files for US East, and the rate data behind Databricks' pricing pages.

Transfer is charged when data leaves the region. Snowflake, for example, lists $0 per TB within the same AWS region, $20 per TB to another AWS region and $90 per TB to the internet from US East. Our workload stays in one region, so the model carries no transfer line. The three lines around the warehouse, ingestion, BI and people, come after the model.

The workload: 5 TB, a burst every 15 minutes, one nightly job

Consider a hypothetical team with this profile:

• 5 TB of data after compression. Each vendor bills storage on its own terms; BigQuery is priced on physical (compressed) bytes to keep the comparison fair.
• A 2-minute query burst every 15 minutes for 10 business hours on 22 weekdays: dashboard refreshes and analysts. That is 40 bursts a day.
• A 1-hour nightly transformation job on the same 22 days.
• One mid-size warehouse. Snowflake Medium ($12 an hour) and Databricks SQL Medium ($16.80 an hour) as the vendors name them. Redshift Serverless at 32 RPU ($12 an hour), the floor AWS recommends "for workloads that have tables with large number columns and higher concurrency". BigQuery Enterprise at 200 slots ($12 an hour), our choice to match.

No vendor publishes an exchange rate between a credit, a slot, an RPU and a DBU, so the sizes are an assumption. We held three of them at the same hourly price on purpose: it isolates what the billing rules do with the same hour.

The busy time is 51.3 hours a month. What each vendor bills depends on what happens in the 13 minutes between bursts.

At the default idle timeout, 75% of billed hours run no query

Snowflake's AUTO_SUSPEND "Default: 600 (the warehouse suspends automatically after 10 minutes of inactivity)". Databricks serverless SQL warehouses: "The default is 10 minutes", with 5 minutes the minimum in the UI and 1 minute through the API. Each 2-minute burst therefore bills 12 minutes, and the warehouse is on for 202 hours a month to do 51 hours of work.

Redshift Serverless has no idle timeout to set. AWS says "You pay only for compute capacity on a per-second basis, with no charges during idle periods", and "The minimum charge is for 60 seconds of resource usage". BigQuery editions are "billed per second with a one-minute minimum duration by default", which we model as a 1-minute tail per burst.

The idle setting moves one warehouse's compute bill 3 times (2.8 times with storage); the hourly price gap between the sizes we picked is 1.4 times. Storage is $115 to $186 in every row. Compute is the line that moves.

BigQuery on demand sits apart because it bills bytes, not time. At $6.25 per TiB after the free first TiB, our 20 TiB is an assumption; the same workload scanning 128 TiB a month would cost as much as the 200-slot Enterprise row. On demand, the variable to measure is bytes per query, and partitioning matters more than any timeout.

The objection: a short timeout costs you the cache

The strongest case against a 60-second timeout comes from Snowflake itself: each warehouse keeps a local cache of table data, and "This cache is dropped when the warehouse is suspended, which might result in slower initial performance for some queries after the warehouse is resumed." If a cold cache doubles each burst from 2 to 4 minutes, the 60-second row grows from 66 to 96 billed hours, still under half the default. Snowflake's own guidance points the same way: "we recommend setting it to a low value (for example, 5 or 10 minutes or less)".

Where the objection wins: bursts that arrive every 2 or 3 minutes. Then the warehouse never suspends at any setting, and the bill is the business day, whatever the timeout says. Measure the gaps between your queries before you change it.

The warehouse invoice is about a sixth of what the platform costs

The brief for a data warehouse rarely stops at the warehouse. Here is the same hypothetical team with the lines around it, at list price:

The warehouse is 16% of the month; one engineer's wage is 76%. Fixing the timeout saves $1,624 a month, about 11% of the total. That is worth doing, and it is also why choosing a vendor on the compute line alone optimizes the smallest of the big numbers.

Practitioners say the same about the people line. David Lequin, describing a data platform team of three at a company of about 500, wrote in October 2026 that most of their week goes on "keeping Snowflake fed, babysitting a dbt project that passed 2,000 models a while ago, and running the Airflow, Airbyte, DataHub and Kubernetes plumbing underneath it all", and that their bill for building a replacement BI tool "leaves out the biggest cost, which is us".

Why the total grows after the first year

The model above is a first month. Platforms rarely stay there, and the growth shows up in the lines nobody owns:

• Dashboards refreshing for nobody. Our 40 bursts a day are scheduled refreshes. If no one opens those dashboards, the 176 billed hours they cause (all but the nightly job's 26) are waste, and no invoice says so.
• Copies across tools. The same tables land in the warehouse, a lake bucket, a BI extract and a dev schema, each billed as storage, and each fed by its own pipeline.
• Tables nobody reads. Storage is cheap per TB, so unused tables stay. Their nightly rebuilds are not cheap; they run on the compute line.
• Dev and test environments left on. A second warehouse at the default timeout, used an hour a day, still bills idle tails on every query.

Each of these lives in a different tool's bill. We cover where this waste hides across the estate in cloud waste in data infrastructure.

Measure your own: one query per platform

Every platform records billed usage in a view you can query. These follow each vendor's documented columns as of October 27, 2026.

Snowflake: idle credits per warehouse. CREDITS_ATTRIBUTED_COMPUTE_QUERIES excludes idle time, so the difference is what the timeout costs you. This is Snowflake's documented idle-cost example, widened to 30 days:

SELECT warehouse_name,
       SUM(credits_used_compute) AS credits,
       SUM(credits_used_compute) - SUM(credits_attributed_compute_queries) AS idle_credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('days', -30, CURRENT_DATE())
  AND end_time < CURRENT_DATE()
GROUP BY warehouse_name
ORDER BY idle_credits DESC;

BigQuery: bytes and slot-hours per user from INFORMATION_SCHEMA.JOBS. total_bytes_billed prices on-demand work; total_slot_ms tells you what the same work would use on editions:

SELECT user_email,
       SUM(total_bytes_billed) / POW(1024, 4) AS tib_billed,
       SUM(total_slot_ms) / 1000 / 3600 AS slot_hours
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND (statement_type IS NULL OR statement_type <> 'SCRIPT')
GROUP BY user_email
ORDER BY tib_billed DESC;

Redshift Serverless: cost per day from SYS_SERVERLESS_USAGE, where charged_seconds is the RPU-seconds billed. Use your region's RPU price:

SELECT TRUNC(start_time) AS day,
       SUM(charged_seconds) / 3600.0 * 0.375 AS cost_usd
FROM sys_serverless_usage
GROUP BY 1
ORDER BY 1;

Databricks SQL: list cost per warehouse from system.billing.usage, where usage_metadata.warehouse_id is set for "Workloads run on a SQL warehouse", joined to system.billing.list_prices:

SELECT u.usage_metadata.warehouse_id,
       SUM(u.usage_quantity) AS dbus,
       SUM(u.usage_quantity * p.pricing.effective_list.default) AS list_cost
FROM system.billing.usage u
JOIN system.billing.list_prices p
  ON  p.sku_name = u.sku_name
  AND p.cloud = u.cloud
  AND u.usage_end_time >= p.price_start_time
  AND (p.price_end_time IS NULL OR u.usage_end_time < p.price_end_time)
WHERE u.usage_metadata.warehouse_id IS NOT NULL
  AND u.usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY ALL
ORDER BY list_cost DESC;

Per-platform detail, including attribution by team and tag, is in Snowflake cost optimization, BigQuery on-demand vs editions and Databricks DBU cost.

What this model does not tell you

• It is list price, read on October 27, 2026. Contracts, committed-use discounts and capacity pricing change every row.
• Sizes are not equivalent. A Snowflake Medium and 32 RPUs may run the same query at different speeds; only your workload on each tells you.
• Scaling is not modeled. Redshift Serverless can scale above its base RPUs and, AWS notes, "RPU capacity can remain at a higher setting for a period after query load falls"; BigQuery's autoscaler adds and removes slots, and multi-cluster warehouses add clusters under load.
• Regions differ. BigQuery is priced in Iowa, the other three in AWS US East.
• The platform table is one hypothetical team. Ingestion is Fivetran's own example, not a quote for your sources.

Where Datapace fits

The bill for a data warehouse sits in four or five invoices and a payroll, and none of them says which dashboard or table the money went to. Datapace is building one map of your data estate with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. If the idle tail above looks like your Snowflake account, start with the five queries in Snowflake cost optimization.

Sources

1. Snowflake, Service Consumption Table, effective October 15, 2026 (credit prices, credits per hour per size, storage and data transfer prices, one-minute minimum).
2. Snowflake docs, CREATE WAREHOUSE, Warehouse considerations and WAREHOUSE_METERING_HISTORY.
3. Google Cloud, BigQuery pricing and INFORMATION_SCHEMA.JOBS.
4. AWS, Amazon Redshift pricing, Amazon Redshift price file for US East, Billing for Redshift Serverless, Understanding Redshift Serverless capacity and SYS_SERVERLESS_USAGE.
5. AWS, Amazon S3 price file for US East.
6. Databricks, AWS rate data for the pricing pages and calculator, docs on SQL warehouse settings, the billable usage table and the pricing table.
7. Fivetran, Pricing; Microsoft, Power BI pricing.
8. U.S. Bureau of Labor Statistics, Database Administrators and Architects, Occupational Outlook Handbook.
9. David Lequin, Can we replace a $150k Looker with a bucket of HTML files?, October 14, 2026.