Convert Google BigQuery to Snowflake
A free online converter that translates Google BigQuery queries into Snowflake. Paste your SQL, press Translate, and Query Studio rewrites the syntax that differs between the two databases — instantly, with no login and nothing stored.
Two cloud warehouses with similar ambitions and different foundations. Types map fairly directly; the nested-data model, the UNNEST/FLATTEN difference, and an inverted cost model are what require thought.
Google BigQuery → Snowflake example
Here is a real Google BigQuery query and the Snowflake output Query Studio produces:
SELECT u.id, u.name, COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2024-01-01' AND u.active = TRUE
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 3
ORDER BY orders DESC
LIMIT 10;SELECT
u.id,
u.name,
COUNT(o.id) AS orders
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.created_at > '2024-01-01'
AND u.active = TRUE
GROUP BY
u.id,
u.name
HAVING
COUNT(o.id) > 3
ORDER BY
orders DESC
LIMIT
10;What changes from Google BigQuery to Snowflake
- The result is re-indented and keyword-cased in Snowflake style so it's ready to paste and run.
Google BigQuery to Snowflake data type mapping
Query Studio translates queries, not schemas. When you come to move the tables themselves, this is what changes between Google BigQuery and Snowflake:
| Google BigQuery | Snowflake | Watch out for |
|---|---|---|
| INT64 | NUMBER(38,0) | Direct equivalent. |
| FLOAT64 | FLOAT | Direct equivalent. |
| STRING | VARCHAR | Direct equivalent. |
| BYTES | BINARY | Direct equivalent. |
| STRUCT<…> | OBJECT / VARIANT | BigQuery structs are strongly typed; Snowflake's OBJECT is not, so field types are checked at read time rather than write time. |
| ARRAY<T> | ARRAY | Snowflake arrays are untyped and can hold mixed values. |
| TIMESTAMP | TIMESTAMP_TZ | Direct equivalent. |
| DATETIME | TIMESTAMP_NTZ | Direct equivalent. |
Google BigQuery to Snowflake: what actually catches people out
Syntax is the part a translator can fix. These are the differences that survive a clean conversion and show up later as wrong results rather than as errors.
Identifier case-folding is opposite in the two engines
BigQuery is case-sensitive for table names and case-insensitive for column names, and does not fold. Snowflake uppercases everything unquoted. The safe route is to lowercase-and-never-quote in BigQuery and let Snowflake fold, rather than carrying quoted mixed-case identifiers across.
STRUCT is typed and OBJECT is not
A BigQuery STRUCT<name STRING, age INT64> has a schema the engine enforces. Snowflake's nearest equivalent, OBJECT, is a VARIANT — untyped, checked at read time. Queries that relied on the struct's field types will still run and will start returning VARIANTs where they expected strings.
SELECT user.name FROM events;SELECT user:name::string FROM events;UNNEST semantics differ
BigQuery's UNNEST is a first-class part of its nested/repeated model and is usually written as a cross join in the FROM clause. Snowflake uses LATERAL FLATTEN, which returns a row set with metadata columns (SEQ, KEY, PATH, INDEX, VALUE) rather than the element directly.
The cost model changes from bytes scanned to warehouse time
BigQuery bills per byte scanned; Snowflake bills for how long a virtual warehouse is running. A query that was expensive in BigQuery because it touched a lot of columns may be cheap in Snowflake, and a slow query that scanned little may now be the expensive one. Optimisation priorities invert.
What this converter will not do
Query Studio translates SQL syntax. Being honest about the boundary is more useful than claiming there isn’t one — and on Google BigQuery → Snowflake specifically, these are the three that matter most:
Performance characteristics
A converted query is correct, not fast. Index strategy, partitioning, distribution keys and statistics differ per engine, and a query that was well-tuned for the source is merely valid on the target. Run the Analyze and Optimize tabs on the output.
Vendor-specific extensions
PostGIS geometry, MySQL spatial functions, SQL Server's FOR XML and hierarchyid, BigQuery's nested/repeated model, Snowflake's time travel. Where there is no equivalent concept, there is no translation — only a redesign.
Stored procedures, functions and triggers
Procedural code — PL/pgSQL, T-SQL procedures, MySQL routines — is a different language in every engine, with different control flow, error handling, variable declaration and transaction semantics. Query Studio translates queries, not programs. These have to be ported by hand.
The full list of what a syntax translator cannot do is on the Query Studio page.
How to convert Google BigQuery to Snowflake
- Open the Query Studio editor and choose Google BigQuery as the “From” dialect.
- Choose Snowflake as the “To” dialect.
- Paste your Google BigQuery query and press Translate — copy the Snowflake result.
Try it with your own query
The editor is preloaded with Google BigQuery → Snowflake. You can also explain, format, validate and analyze the result.
Convert Google BigQuery to Snowflake now →Working with the data rather than the schema? Open a large CSV, JSON or Parquet file and query it with SQL — no upload, no row limit, and files far past what Excel will open.
Google BigQuery to Snowflake FAQ
Is this Google BigQuery to Snowflake converter free?
Yes — it's completely free with no account, no sign-up and no usage limits. Your query is processed to return the result and never stored.
Is the Google BigQuery to Snowflake conversion accurate?
Query Studio rewrites syntax deterministically using real SQL parsers, so it gives the same result every time — there is no AI involved and no variation between runs. It handles the differences listed above automatically. What it cannot do is anything semantic: stored procedures, triggers, vendor extensions and performance characteristics all need a human. Review complex, vendor-specific queries before running them in production.
What breaks when migrating from Google BigQuery to Snowflake?
The differences that most often cause problems on this pair: Identifier case-folding is opposite in the two engines; STRUCT is typed and OBJECT is not; UNNEST semantics differ; The cost model changes from bytes scanned to warehouse time. Each is explained in full above, with before-and-after examples where seeing it is quicker than reading about it.
How do Google BigQuery data types map to Snowflake?
The full mapping table is above and covers 8 types. The ones that are not a straight rename: STRUCT<…> → OBJECT / VARIANT, ARRAY<T> → ARRAY. Note that Query Studio translates queries rather than schemas — the table is there to tell you what your CREATE TABLE statements need, not to rewrite them for you.
Does this Google BigQuery to Snowflake converter use AI?
No. Every result is computed by real SQL parsers and rule engines, which is what makes it free, instant, unlimited and identical on every run. Nothing is sent to a model, so there are no rate limits, no per-request cost to pass on, and no possibility of a confidently wrong answer that looks plausible.