Skip to content
All services
Solution · Snowflake → BigQuery

Snowflake to BigQuery, reconciled object-by-object.

From credit economics to slot economics, JS UDFs to SQL UDFs, Time Travel to table snapshots. Codified translation rules carry the bulk of the dialect work; the rest is named in the Discovery report before execution starts.

The shape of this migration

Snowflake to BigQuery is roughly 80-85% dialect-overlap and 15-20% rewrite. The rewrite work concentrates in five places: JavaScript UDFs, Time Travel-dependent workflows, semi-structured (VARIANT) access patterns, stored procedures, and BI-tool semantic layers tied to Snowflake-specific functions. The rest is mechanical translation handled by the rule library.

The harder decisions are architectural, not dialect-level. CLUSTER BY column choice, partition strategy, slot commitment shape, Iceberg-vs-native storage call per dataset, and whether to consolidate or split downstream BI access. The Discovery report enumerates these per dataset with the trade-off shown.

What typically breaks first

  • JavaScript UDFs. Snowflake JS UDFs do not have a direct BigQuery analogue. Most rewrite as BigQuery SQL UDFs; a minority become BigQuery JavaScript UDFs (different runtime); a small subset move to Cloud Run as remote functions. Discovery enumerates each one with the chosen path.
  • Stored procedures. Snowflake JavaScript stored procs become BigQuery routines or scheduled queries. Control-flow-heavy procs sometimes move out of the warehouse entirely into Cloud Workflows or Composer.
  • Time Travel-dependent debugging. Any workflow that uses time travel for audit, debugging, or "what was the table at time T" gets replaced with BigQuery table snapshots — but the team's debugging muscle has to move with it. Parallel run keeps both alive for 2-4 weeks.
  • BI semantic layers. Looker, Tableau, or Sigma models referencing Snowflake-specific functions (PIVOT variants, semi-structured paths, QUALIFY edge cases) need a regen against the BigQuery target. Discovery enumerates the BI surface explicitly so this lands in the wave plan, not at week 9.
  • dbt model fan-out. dbt model graphs that worked cheaply on Snowflake credits sometimes blow up on BigQuery slot economics — a model that re-reads source-table data 12 times is much more expensive under slot pricing. The fan-out audit catches this before cutover.

What you receive at each wave

  • Written inventory: every table, view, UDF, stored proc, dbt model, BI artifact, with the chosen translation path.
  • Translated DDL + DML, generated from the codified rule library + bespoke handlers for the residual.
  • Reconciliation report per wave: row-count parity, schema parity, float-tolerant checksums, query-result diffs on top-50 + top-20-by-cost queries.
  • Parallel-run window: 2-4 weeks of source + target both live with daily diff reports until consumer owners sign off per-dashboard.
  • Cutover document co-signed by your platform lead + ours. You keep it forever.

Related reading on this pair

Background on the dialect work, slot economics, and the cutover playbook lives in the writing section:

How to start

The fast path is a Cloud Cost X-Ray on the Snowflake side — currently free 90-min review (through Q3 2026), names the top-20 waste sources and the rewrite shape before any migration commitment. The free framing runs through Q3 2026; after that the same review reverts to a $100 5-day paid diagnostic, credited 100% to Execution if you sign within 60 days. If your situation is already past the diagnostic phase, book a 30-minute call and we will quote the Discovery Sprint directly.

Questions buyers actually ask

Before you book a call.

Why move from Snowflake to BigQuery in 2026? ▾
Three common drivers. First, GCP-native gravity — when the rest of the stack (apps, ML, BI) is already on GCP, the warehouse co-location reduces egress and IAM surface. Second, slot economics — for predictable workloads, a slot commitment can beat Snowflake credit pricing materially. Third, ML/AI workload gravity — Vertex AI, AlloyDB AI, and BigQuery ML integration vs the Snowpark / Cortex stack. We will tell you when the move does not pencil — sometimes the right answer is to stay on Snowflake and rebuild the workload.
What is the realistic SQL dialect translation surface? ▾
Snowflake and GoogleSQL are 80-85% overlapping. The 15-20% that does not translate cleanly: Snowflake JS UDFs (rewritten as BigQuery SQL UDFs or remote functions in Cloud Run), QUALIFY clauses (BigQuery has them but with edge-case differences), PIVOT syntax, semi-structured access (VARIANT vs STRUCT), Time Travel (replaced with table snapshots), zero-copy clone (replaced with table copy + scheduled refresh), and stored procedures (Snowflake JS procs → BigQuery JavaScript or routine rewrites). The codified rule library handles the bulk; the residual is bespoke per estate.
How is CLUSTER BY different from a Snowflake clustering key — what changes for our existing tables? ▾
BigQuery CLUSTER BY supports up to 4 columns and re-clusters automatically (no explicit RECLUSTER call). Snowflake cluster keys behave similarly but the recommended cardinality and ordering differ. Partition keys in BigQuery (by date or integer range) have no Snowflake equivalent — moving from a single Snowflake cluster key to a BigQuery partition + cluster pair is one of the largest performance wins available in the migration, but requires a column choice that the Discovery report makes explicit per table.
What happens to our Time Travel and zero-copy clones? ▾
Time Travel is replaced with BigQuery table snapshots (point-in-time snapshots with a configurable retention window). Zero-copy clones are replaced with table copies or scheduled DDL refreshes. Where workflows depended on time-travel for debugging, the parallel-run phase keeps both warehouses live for 2-4 weeks so the debugging muscle moves over before the source is decommissioned.
What about Iceberg — should we land Snowflake data in BigQuery managed storage or in Iceberg-on-GCS? ▾
It depends on whether you want the data accessible from Databricks or other Iceberg-native engines. Managed BigQuery storage is the default — better performance, simpler ops, lower cost for BigQuery-only access. Iceberg-on-GCS is the choice when the same data needs to be queried from Databricks, Trino, or Spark outside BigQuery. The Discovery report makes the call per dataset based on consumer topology; mixed estates are common.
How long does a typical Snowflake → BigQuery take? ▾
Discovery Sprint is 10 business days fixed. Execution depends on inventory: small estates (under 200 tables, 500 dbt models) execute in 8-12 weeks; mid-market (200-800 tables, 1000-5000 dbt models, 20-60 downstream consumers) in 12-20 weeks; large or regulated (1000+ tables) in 24-32 weeks. The number on your estate is in the Discovery deliverable with the reasoning shown.
What does reconciliation actually look like at the end? ▾
Per wave: row-count parity per table, schema parity (column types, nullability, defaults), float-tolerant checksums on every migrated table, and query-result diffs on the top 50 most-frequent queries and top 20 most-expensive queries. Co-signed at cutover by your platform lead and ours. Deterministic — no model grades its own output.