Snowflake to BigQuery migration without hand-written unload scripts
The Snowflake to BigQuery migration path from Adapters copies tables, casts Snowflake types to their BigQuery equivalents, and loads on an incremental schedule, so you can run both warehouses in parallel during a cutover instead of freezing reporting for a big-bang unload. Field mapping is no-code, so try it against sample records in the live demo.
The live demo needs no card, and Starter is $49 a month.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
What running Snowflake to BigQuery by hand costs you
- A one-shot unload to cloud storage and reload into BigQuery freezes reporting during the cutover, and any table that changes mid-migration has to be redone by hand.
- Snowflake and BigQuery disagree on types: VARIANT, TIMESTAMP_NTZ versus TIMESTAMP_TZ, and NUMBER precision all need deliberate casting or numbers and dates land subtly wrong.
- Dashboards and models have to be validated against both warehouses before you switch, which means keeping the two in agreement for weeks, not copying once.
The field mapping, out of the box
All 6 of these Snowflake to BigQuery fields arrive mapped. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.
Input / SNOWFLAKE
Output / BIGQUERY
Transforms included
Snowflake NUMBER casts to BigQuery NUMERIC or BIGNUMERIC by declared precision and scale, VARIANT and OBJECT columns land as JSON, TIMESTAMP_NTZ is stamped to UTC as TIMESTAMP so no hour shifts on the way across, and VARCHAR maps to STRING. Incremental runs use an updated-at watermark per table, target tables partition by the load date, and writes MERGE on the primary key so you can re-run a window during parallel validation without duplicating a single row.
Snowflake to BigQuery in depth
Two warehouses with similar pitches and genuinely different limits. Everything here is from Snowflake and Google Cloud documentation, checked 31 August 2026.
Identifier case folds in opposite directions
Snowflake folds unquoted identifiers to UPPERCASE. BigQuery does not fold at all, and its table names are case sensitive. A Snowflake export producing ORDERS and a BigQuery pipeline expecting orders will fail with a table-not-found error that reads like a permissions problem. Decide the casing convention once and apply it in the unload step, not in every downstream query.
Both default their numeric types badly for money
Snowflake NUMBER defaults to (38,0), which has no scale, so cents disappear without an error. On the BigQuery side the correct money type is NUMERIC, which carries 38 digits of precision and 9 of scale, and the wrong one is FLOAT64. A migration that lets both defaults through loses precision twice for the same reason and reconciles perfectly on row count.
BigQuery load job quotas are the real ceiling
BigQuery allows 1,500 load jobs per table per day and 100,000 per project per day. A pipeline landing one file per table every minute reaches the per-table ceiling before lunch. Batch the loads instead: batch load jobs run free on a shared slot pool, so consolidating them costs nothing and buys back the whole allocation.
Size limits differ enough to matter
BigQuery caps a load job at 15 TB with a 6 hour execution limit, allows 10,000 columns per table, and rejects CSV or newline-delimited JSON rows above 100 MB. Compressed CSV and JSON files are capped at 4 GB each. Snowflake VARIANT and VARCHAR values can reach 128 MB, so a wide semi-structured column that Snowflake accepts can exceed the BigQuery row limit on arrival.
Semi-structured data does not map one to one
Snowflake VARIANT and BigQuery JSON both hold arbitrary structure and behave differently under querying and cost. Snowflake extracts a maximum of 200 elements per partition. Flattening the columns you actually query into typed fields, and keeping the raw payload as a single JSON column alongside, is cheaper and less surprising than trying to make one engine imitate the other.
Unload file sizing is the whole performance story
Snowflake recommends staged files of 100 to 250 MB compressed. BigQuery loads split cleanly from many moderate files and serially from one large compressed one. Unloading a large table as a single gzip file makes both sides slow for the same reason, and the fix is one parameter in the COPY INTO statement rather than a larger warehouse.
This is a migration, so plan the parallel run
Warehouse to warehouse moves almost never cut over cleanly, because dashboards, scheduled queries and reverse ETL jobs all point at the old one. Expect a period where both are loaded and reconciled daily. Price that period deliberately: it is the line item that turns a two month project into a two quarter one, and it is covered on our data migration cost guide.
What we do about all of it
The field mapping is declared once with the BigQuery type stated explicitly, so NUMERIC is chosen for money rather than inferred from a sample. Loads are batched to stay well inside the per-table job quota, files are unloaded in the recommended size range, and the incremental run merges on the key so a replay cannot double-count. The reverse direction has its own trade-offs and is covered on the BigQuery to Snowflake connector.
How it goes live
Moving Snowflake data into BigQuery on flat data integration pricing from $49 a month.
STEP 01
Pick the pair
Authorize a read scope on Snowflake and a write scope on BigQuery, nothing wider.
STEP 02
Confirm the mapping
Check that SNOWFLAKE.ORDERS.ORDER_ID lands in orders.order_id and SNOWFLAKE.ORDERS.UPDATED_AT in orders.loaded_at on a sample record.
STEP 03
Schedule the sync
Turn on the SNOWFLAKE → BIGQUERY schedule; failed records retry and every run is logged.
Snowflake to BigQuery sync common questions
How do I migrate from Snowflake to BigQuery?
Unload Snowflake tables to cloud storage as Parquet, load them into BigQuery, then port the SQL and run both warehouses in parallel until the numbers agree. Migrate one reporting domain at a time so you always have a working system, and validate with row counts plus a checksum on the numeric columns per table.
What are the main Snowflake to BigQuery migration challenges?
Identifier case, semi-structured data and the billing model. Snowflake folds unquoted identifiers to uppercase while BigQuery column names are case sensitive as created, so a blind copy breaks queries. VARIANT columns become JSON or a defined STRUCT, and FLATTEN becomes UNNEST. The bigger shift is operational: you move from per-second warehouse credits to paying for bytes scanned, so partitioning and clustering become the main cost lever.
How do Snowflake types map to BigQuery?
VARCHAR becomes STRING, NUMBER with scale zero becomes INT64 and scaled NUMBER becomes NUMERIC or BIGNUMERIC, FLOAT becomes FLOAT64, BINARY becomes BYTES, and BOOLEAN becomes BOOL. TIMESTAMP_NTZ becomes DATETIME, TIMESTAMP_TZ and TIMESTAMP_LTZ become TIMESTAMP, and VARIANT, OBJECT and ARRAY become JSON or an explicit STRUCT and ARRAY definition.
Is BigQuery cheaper than Snowflake?
Neither is categorically cheaper; they bill for different things. BigQuery on-demand charges for bytes scanned, so wide unpartitioned tables and frequent dashboard refreshes are what cost you. Snowflake charges for warehouse time, so idle warehouses and oversized clusters are what cost you. Model your own top twenty queries against both before assuming a saving.
How does the Snowflake to BigQuery sync work?
The Snowflake to BigQuery migration path from Adapters copies tables, casts Snowflake types to their BigQuery equivalents, and loads on an incremental schedule, so you can run both warehouses in parallel during a cutover instead of freezing reporting for a big-bang unload. Field mapping is no-code, so try it against sample records in the live demo.
How much does the Snowflake BigQuery integration cost?
The Snowflake to BigQuery pair is included on every plan: Starter $49, Growth $149, Scale $399 a month. You pay per plan, not per row or task, so a busier month costs the same.
Do I need to write code to connect Snowflake and BigQuery?
No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Snowflake NUMBER casts to BigQuery NUMERIC or BIGNUMERIC by declared precision and scale, VARIANT and OBJECT columns land as JSON, TIMESTAMP_NTZ is stamped to UTC as TIMESTAMP so no hour shifts on the way across, and VARCHAR maps to STRING. Incremental runs use an updated-at watermark per table, target tables partition by the load date, and writes MERGE on the primary key so you can re-run a window during parallel validation without duplicating a single row.
Related Snowflake and BigQuery connectors
Browse the full api connector library, or request a pair you do not see.
Snowflake and BigQuery, finally in agreement
Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.
The live demo needs no card, and Starter is $49 a month.