Warehouse Cost Translator
Paste real BigQuery job history and get a modelled range for the same workload on Snowflake and Databricks. The shape comes from your data; the slot-to-credit bridge is an assumption, shown as a dial and reported as a range.
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; this page has no backend to send it to.
-- Run in BigQuery. Returns hourly aggregates only: -- no query text, no table names, no user identities. SELECT TIMESTAMP_TRUNC(creation_time, HOUR) AS hour, COUNT(*) AS jobs, SUM(total_bytes_billed) AS bytes_billed, SUM(total_slot_ms) AS slot_ms FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY) AND job_type = 'QUERY' GROUP BY hour ORDER BY hour
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
As with the individual calculators, this tool publishes no Snowflake or Databricks rate card — those are contract-specific and almost nobody pays list.
What this model assumes
- 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 planning figures with no vendor authority behind them, which is why every cost is a range and the dials are on the page.
- 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 plus the cloud VMs underneath. The second is usually the larger, and a comparison that prices only DBUs understates the platform by roughly two thirds.
- 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 materialisation all behave differently.
- Compute only. 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.
- Nothing is uploaded. The paste is parsed in your browser and never encoded into the permalink — the URL is the one piece of page state that reliably escapes, so pasted data never goes in it.
Frequently asked 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 states it, exposes it as a slider, and reports a range rather than a single figure. If moving the slider inside its plausible band flips the decision, the honest answer is that 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 materialisation 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.
A migration is a decision. Running the estate is the job.
Finitizer models BigQuery, Snowflake, Databricks and Redshift against your real consumption continuously — so the platform question gets answered with data, and the cost of whichever one you keep gets managed rather than estimated.