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.

Try it in the live demo

No credit card required.

Input

Output

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Last updated September 2026

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

These cables are pre-wired when you pick the pair. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.

Input / SNOWFLAKE

Output / BIGQUERY

SNOWFLAKE.ORDERS.ORDER_ID

orders.order_id

SNOWFLAKE.ORDERS.TOTAL_AMOUNT

orders.total_amount

SNOWFLAKE.ORDERS.CREATED_AT

orders.created_at

SNOWFLAKE.ORDERS.PAYLOAD

orders.payload

SNOWFLAKE.CUSTOMERS.EMAIL

customers.email

SNOWFLAKE.ORDERS.UPDATED_AT

orders.loaded_at

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

Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.

STEP 01

Pick the pair

Connect Snowflake and BigQuery with scoped credentials. About a minute each.

STEP 02

Confirm the mapping

The cables above are pre-wired. Adjust any field, preview the transform on sample records, done.

STEP 03

Schedule the sync

Hourly down to every minute, with retries, alerting, and a full log on every run.

Prefer to understand the moving parts first? Our long-form guide to the Snowflake to BigQuery migration guide covers the field-by-field detail, the failure cases, and what changes at volume.

Try it in the live demo Preloads SNOWFLAKE → BIGQUERY with sample records

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?

Is there a prebuilt Snowflake connector for BigQuery?

Yes. This Snowflake to BigQuery connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and you can try it against sample records in the live demo. No code or engineering sprint required.

How much does the Snowflake BigQuery integration cost?

Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.

How often can Adapters sync Snowflake to BigQuery?

Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.

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.

More pairs from the API connector library

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.

Try the live demo

No credit card required.