Warehouse Cost Translator
See what your BigQuery workload would cost moved to Snowflake or Databricks, from your own job history.
Before you start: what to have readyShow
- A week or more of BigQuery job history. The page gives you one query to run against BigQuery's INFORMATION_SCHEMA job views; it returns hourly totals for the last 30 days. Paste the result grid with its header row. Below a week of history the tool shows the workload shape but no cost.
- Your Snowflake credit price and Databricks discount, if you have them. Both start at list price, which both vendors publish, and almost nobody pays list.
- The instance type a Databricks cluster would use, and the auto-suspend setting you would give a Snowflake warehouse.
- Any commitment you already have. These figures are pay-as-you-go on every platform, so if one side carries a commitment discount, compare like with like.
1. Extract your BigQuery job history
This query returns hourly aggregates only: job counts, bytes billed and slot-milliseconds. No query text, no table or dataset names, no user identities. Everything below runs in your browser and nothing you paste is transmitted.
-- Finitizer Slot Advisor extract: hourly aggregates only.
-- Returns no query text, no table names, and no user identities.
-- Slot time is booked to the hour it was used (JOBS_TIMELINE), so a job that
-- runs for three hours counts in each of them. Bytes and job counts come from
-- JOBS, by the hour each job was created. Script parents are left out, so a
-- script's statements are counted once.
WITH slot_time AS (
SELECT
TIMESTAMP_TRUNC(period_start, HOUR) AS hour,
SUM(period_slot_ms) AS slot_ms
FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 31 DAY)
AND period_start >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
GROUP BY hour
),
job_totals AS (
SELECT
TIMESTAMP_TRUNC(creation_time, HOUR) AS hour,
COUNT(*) AS jobs,
SUM(total_bytes_billed) AS bytes_billed,
APPROX_QUANTILES(
SAFE_DIVIDE(
total_slot_ms,
NULLIF(TIMESTAMP_DIFF(end_time, start_time, MILLISECOND), 0)
), 100
)[OFFSET(95)] AS p95_job_avg_slots
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND (statement_type != 'SCRIPT' OR statement_type IS NULL)
AND total_slot_ms IS NOT NULL
GROUP BY hour
)
SELECT
COALESCE(j.hour, s.hour) AS hour,
IFNULL(j.jobs, 0) AS jobs,
IFNULL(j.bytes_billed, 0) AS bytes_billed,
IFNULL(s.slot_ms, 0) AS slot_ms,
j.p95_job_avg_slots AS p95_job_avg_slots
FROM job_totals j
FULL OUTER JOIN slot_time s ON s.hour = j.hour
ORDER BY 1;The bridge: the assumption doing the work
BigQuery sells slots, Snowflake sells credits, Databricks sells DBUs, and no vendor publishes a conversion between them. Any tool that translates between these platforms is making an assumption; this one lets you move it and see whether the answer survives. If the decision flips inside the plausible band, the honest conclusion is that a rate card cannot settle it and you need a proof of concept.
Your rates
Both start at list price: Snowflake’s Enterprise credit in AWS US East, and Databricks’ rate card for the cloud and plan picked. Most contracts are not list, so enter yours.
What this model assumes
Show
- The workload shape is yours; the translation is not. Concurrency, duty cycle and burst come from your own INFORMATION_SCHEMA export. The slot-to-credit and slot-to-DBU bridges are guesses with no vendor authority behind them, which is why the page leads with the conversion each platform needs to beat your BigQuery bill.
- Snowflake is billed for being awake. The model charges every active hour plus an auto-suspend tail after each active-to-idle transition, not just the hours that did work. That is how Snowflake actually bills, and it is where a low-duty-cycle BigQuery workload gets expensive.
- Databricks is charged twice. DBUs on the Databricks invoice, plus the cloud VMs underneath on your cloud provider’s. How the two split depends on the compute type and your rates, so the Databricks card shows both for your data; a comparison that prices only DBUs leaves the second invoice out. Like Snowflake, a cluster sized to your mean demand bills every active hour. Serverless SQL is the exception: its DBU rate includes the compute. Classic and Pro SQL VMs are on your cloud bill and are not included.
- A lifted workload is not a rewritten one. These figures assume the same queries doing the same work. Real migrations rewrite for the target engine, which can move the answer in either direction: clustering, result caching and materialization all behave differently.
- Compute only, list prices. The BigQuery figures are US multi-region list prices. Storage, data transfer, streaming ingest, serverless features and the cost of the migration itself are all excluded. Storage in particular is broadly comparable across the three and would add a similar number to every column.
- No upload needed. The paste is parsed in your browser and sent nowhere unless you choose to share it for a review, and none of it goes into the page URL, the one piece of page state that reliably escapes.
Want this done on your real bill?
BigQuery Cost Audit: We find the queries, tables and slots driving your BigQuery bill and fix them without slowing anyone down. From $2,500, fixed. Nothing paid upfront.
About this tool
Questions
Can you convert BigQuery slots to Snowflake credits?
Not authoritatively, no vendor publishes a conversion, and none of them describes a slot, a credit or a DBU in terms of vCPU. Any tool that claims to translate between these platforms is making an assumption. This one leads with the break-even instead: how many slots one credit would have to do the work of for Snowflake to cost less than your BigQuery bill. If your workload would not plausibly clear that line, the answer is clear; if it is close, a rate card cannot settle it and you need a proof of concept.
Is Snowflake cheaper than BigQuery?
It depends far more on the shape of your workload than on the rates. BigQuery on-demand bills bytes scanned and charges nothing when idle. Snowflake bills a warehouse for being awake, including the auto-suspend tail after each burst of activity. So a workload that runs constantly can be cheaper on Snowflake, and one that runs in short bursts across the day frequently is not, which is exactly why this tool starts from your real hourly history rather than a monthly total.
Why does this need a full week of history?
Because a migration argument is the wrong place for a confident number derived from a partial day. A week captures the weekday and weekend shape that drives most of the answer. Below that, the tool shows your workload profile and deliberately prints no cost at all, the same rule the BigQuery query analyzer applies when it has no schema.
Does this include storage costs?
No, and deliberately. Storage is broadly comparable across the three platforms and would add a similar figure to every column without changing the comparison. What is excluded matters more here than usual: data transfer, streaming ingest, serverless features and the cost of the migration itself are all outside the model.
Will my queries cost the same after a migration?
Almost certainly not. These figures assume the same queries doing the same work, and real migrations rewrite for the target engine. Clustering, result caching and materialization behave differently on each platform, and that can move the answer in either direction. Treat this as a starting position for a business case, not as the business case.
Related tools
Snowflake Cost Calculator
Snowflake bills while your warehouse is awake, not only while it runs queries.
OpenDatabricks Cost Calculator
The Databricks bill leaves out the cloud VMs. This prices both.
OpenBigQuery Slot vs On-Demand Advisor
Find out whether BigQuery Editions slots would actually save you money.
OpenMore tools for: Analytics and warehouses
A migration is a decision. Running the estate is the job.
Finitizer does this for BigQuery today. Snowflake and Redshift support is on the way.
See how Finitizer works