Snowflake SQL translation guide

This document details the similarities and differences in SQL syntax between Snowflake and BigQuery to help accelerate the planning and execution of moving your EDW (Enterprise Data Warehouse) to BigQuery. Snowflake data warehousing is designed to work with Snowflake-specific SQL syntax. Scripts written for Snowflake might need to be altered before you can use them in BigQuery, because the SQL dialects vary between the services. Use batch SQL translation to migrate your SQL scripts in bulk, or interactive SQL translation to translate ad-hoc queries.

Data types

This section shows equivalents between data types in Snowflake and in BigQuery.

Snowflake	BigQuery	Notes
`NUMBER/ DECIMAL/NUMERIC`	`NUMERIC`	The `NUMBER` data type in Snowflake supports 38 digits of precision and 37 digits of scale. Precision and scale can be specified according to the user. The `NUMERIC` data type in BigQuery supports 38 digits of precision and 9 digits of scale. BigQuery does not support custom digit or scale bounds.
`INT/INTEGER`	`INT64`
`BIGINT`	`INT64`
`SMALLINT`	`INT64`
`TINYINT`	`INT64`
`BYTEINT`	`INT64`
`FLOAT/ FLOAT4/ FLOAT8`	`FLOAT64`	The `FLOAT` data type in Snowflake establishes 'NaN' as > X, where X is any FLOAT value (other than 'NaN' itself). The `FLOAT` data type in BigQuery establishes 'NaN' as < X, where X is any FLOAT value (other than 'NaN' itself).
`DOUBLE/ DOUBLE PRECISION/` `REAL`	`FLOAT64`	The `DOUBLE` data type in Snowflake is synonymous with the `FLOAT` data type in Snowflake, but is commonly incorrectly displayed as `FLOAT`. It is properly stored as `DOUBLE`.
`VARCHAR`	`STRING`	The `VARCHAR` data type in Snowflake has a maximum length of 16 MB (uncompressed). If length is not specified, the default is the maximum length. The `STRING` data type in BigQuery is stored as variable length UTF-8 encoded Unicode. The maximum length is 16,000 characters.
`CHAR/CHARACTER`	`STRING`	The `CHAR` data type in Snowflake has a maximum length of 1.
`STRING/TEXT`	`STRING`	The `STRING` data type in Snowflake is synonymous with Snowflake's VARCHAR.
`BINARY`	`BYTES`
`VARBINARY`	`BYTES`
`BOOLEAN`	`BOOL`	The `BOOL` data type in BigQuery can only accept `TRUE/FALSE`, unlike the `BOOL` data type in Snowflake, which can accept TRUE/FALSE/NULL.
`DATE`	`DATE`	The `DATE` type in Snowflake accepts most common date formats, unlike the `DATE` type in BigQuery, which only accepts dates in the format, 'YYYY-[M]M-[D]D'.
`TIME`	`TIME`	The TIME type in Snowflake supports 0 to 9 nanoseconds of precision, whereas the TIME type in BigQuery supports 0 to 6 nanoseconds of precision.
`TIMESTAMP`	`TIMESTAMP`
`TIMESTAMP_LTZ`	`TIMESTAMP`
`TIMESTAMP_NTZ/DATETIME`	`TIMESTAMP`
`TIMESTAMP_TZ`	`TIMESTAMP`
`OBJECT`	`STRUCT`	The `OBJECT` type in Snowflake does not support explicitly-typed values. Values are of the `VARIANT` type. The `STRUCT` type in BigQuery only supports explicitly-typed values.
`ARRAY`	`ARRAY`	The `ARRAY` type in Snowflake can only support `VARIANT` types, whereas the ARRAY type in `BigQuery` can support all data types with the exception of an array itself. The Snowflake `ARRAY` types can support NULL values via `VARIANT` types, whereas BigQuery ARRAY types do not.

BigQuery also has the following data types which do not have a direct Snowflake analogue:

Snowflake also has the following data types which do not have a direct BigQuery analogue:

VARIANT

General reference

This section provides details on general references in Snowflake and their mapping to references in BigQuery.

Query syntax and query operators

This section addresses differences in query syntax between Snowflake and BigQuery.

SELECT statement

Most Snowflake SELECT statements are compatible with BigQuery. The following table contains a list of minor differences.

Snowflake BigQuery

Snowflake	BigQuery
`SELECT TOP ...` `FROM table`	`SELECT expression` `FROM table` `ORDER BY expression DESC` `LIMIT number`
`SELECT` `x/total AS probability,` `ROUND(100 * probability, 1) AS pct` `FROM raw_data` Note: Snowflake supports creating and referencing an alias in the same `SELECT` statement.	`SELECT` `x/total AS probability,` `ROUND(100 * (x/total), 1) AS pct` `FROM raw_data`
`SELECT * FROM (` `VALUES (1), (2), (3)` `)`	`SELECT AS VALUE STRUCT(1, 2, 3)`

SELECT TOP ...

FROM table

SELECT expression

FROM table

ORDER BY expression DESC

LIMIT number

SELECT

x/total AS probability,

ROUND(100 * probability, 1) AS pct

FROM raw_data

Note: Snowflake supports creating and referencing an alias in the same SELECT statement.

SELECT

x/total AS probability,

ROUND(100 * (x/total), 1) AS pct

FROM raw_data

SELECT * FROM (

VALUES (1), (2), (3)

)

SELECT AS VALUE STRUCT(1, 2, 3)

Snowflake aliases and identifiers are case-insensitive by default. To preserve case, enclose aliases and identifiers with double quotes (").

BigQuery supports the following expressions in SELECT statements, which do not have a Snowflake equivalent:

FROM clause

A FROM clause in a query specifies the possible tables, views, subquery, or table functions to use in a SELECT statement. All of these table references are supported in BigQuery.

The following table contains a list of minor differences.

Snowflake		BigQuery
`SELECT $1, $2 FROM (VALUES (1, 'one'), (2, 'two'));`		`WITH table1 AS ( SELECT STRUCT(1 as number, 'one' as spelling) UNION ALL SELECT STRUCT(2 as number, 'two' as spelling) ) SELECT * FROM table1`
`SELECT` `FROM table` `PIVOT` `(aggregate(pivot_column)` `FOR value_column IN` `(pivot_value_1[,` `pivot_value_2 ...]))` `...` `SELECT FROM table` `UNPIVOT` `(value_column` `FOR name_column in` `(column_list))` `...`		BigQuery does not offer a direct alternative to Snowflake's `PIVOT/UNPIVOT.`
`SELECT* FROM table SAMPLE(10)`		`SELECT* FROM table` `TABLESAMPLE` `BERNOULLI (0.1 PERCENT)`
`SELECT * FROM table1 AT(TIMESTAMP => timestamp) SELECT * FROM table1 BEFORE(STATEMENT => statementID)`		`SELECT * FROM table` `FOR SYSTEM_TIME AS OF timestamp` Note: BigQuery does not have a direct alternative to Snowflake's BEFORE using a statement ID. The value of timestamp cannot be more than 7 days before the current timestamp.
`@[namespace]<stage_name>[/path]`		BigQuery does not support the concept of staged files.
`SELECT*` `FROM table` `START WITH predicate` `CONNECT BY` `[PRIOR] col1 = [PRIOR] col2` `[, ...]` `...`		BigQuery does not offer a direct alternative to Snowflake's `CONNECT BY`.

BigQuery tables can be referenced in the FROM clause using:

[project_id].[dataset_id].[table_name]
[dataset_id].[table_name]
[table_name]

BigQuery also supports additional table references:

Historical versions of the table definition and rows using FOR SYSTEM_TIME AS OF
Field paths, or any path that resolves to a field within a data type (that is, a STRUCT)
Flattened arrays

WHERE clause

The Snowflake WHERE clause and BigQuery WHERE clause are identical, except for the following:

Snowflake		BigQuery
`SELECT col1, col2 FROM table1, table2 WHERE col1 = col2(+)`		`SELECT col1, col2 FROM table1 INNER JOIN table2 ON col1 = col2`Note: BigQuery does not support the `(+)` syntax for `JOIN`s

JOIN types

Both Snowflake and BigQuery support the following types of join:

[INNER] JOIN
LEFT [OUTER] JOIN
RIGHT [OUTER] JOIN
FULL [OUTER] JOIN
CROSS JOINand the equivalent implicit "comma cross join"

Both Snowflake and BigQuery support theONandUSING clause.

The following table contains a list of minor differences.

Snowflake BigQuery

Snowflake	BigQuery
`SELECT col1` `FROM table1` `NATURAL JOIN` `table2`	`SELECT col1` `FROM table1` `INNER JOIN` `table2` `USING (col1, col2 [, ...])` Note: In BigQuery, `JOIN` clauses require a JOIN condition unless it is a CROSS JOIN or one of the joined tables is a field within a data type or an array.
`SELECT ... FROM table1 AS t1, LATERAL ( SELECT*` `FROM table2 AS t2` `WHERE t1.col = t2.col )` Note: Unlike the output of a non-lateral join, the output from a lateral join includes only the rows generated from the in-line view. The rows on the left-hand side do not need to be joined to the right hand side because the rows on the left-hand side have already been taken into account by being passed into the in-line view.	`SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2` `ON t1.col = t2.col` Note: BigQuery does not support a direct alternative for `LATERAL JOIN`s.

SELECT col1

FROM table1

NATURAL JOIN

table2

SELECT col1

FROM table1

INNER JOIN

table2

USING (col1, col2 [, ...])

Note: In BigQuery, JOIN clauses require a JOIN condition unless it is a CROSS JOIN or one of the joined tables is a field within a data type or an array.

SELECT ... FROM table1 AS t1, LATERAL ( SELECT*

FROM table2 AS t2

WHERE t1.col = t2.col )

Note: Unlike the output of a non-lateral join, the output from a lateral join includes only the rows generated from the in-line view. The rows on the left-hand side do not need to be joined to the right hand side because the rows on the left-hand side have already been taken into account by being passed into the in-line view.

SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2

ON t1.col = t2.col

Note: BigQuery does not support a direct alternative for LATERAL JOINs.

WITH clause

A BigQuery WITH clause contains one or more named subqueries which execute every time a subsequent SELECT statement references them. Snowflake WITH clauses behave the same as BigQuery with the exception that BigQuery does not support WITH RECURSIVE.

GROUP BY clause

Snowflake GROUP BY clauses support GROUP BY, GROUP BY ROLLUP, GROUP BY GROUPING SETS, and GROUP BY CUBE, while BigQuery GROUP BY clauses supports GROUP BY and GROUP BY ROLLUP.

Snowflake HAVING and BigQuery HAVING are synonymous. Note that HAVING occurs after GROUP BY and aggregation, and before ORDER BY.

Snowflake BigQuery

Snowflake	BigQuery
`SELECT col1 as one, col2 as two` `FROM table GROUP BY (one, 2)`	`SELECT col1 as one, col2 as two` `FROM table GROUP BY (one, 2)`
`SELECT col1 as one, col2 as two` `FROM table GROUP BY ROLLUP (one, 2)`	`SELECT col1 as one, col2 as two` `FROM table GROUP BY ROLLUP (one, 2)`
`SELECT col1 as one, col2 as two` `FROM table GROUP BY GROUPING SETS (one, 2)` Note: Snowflake allows up to 128 grouping sets in the same query block	BigQuery does not support a direct alternative to Snowflake's `GROUP BY GROUPING SETS`.
`SELECT col1 as one, col2 as two` `FROM table GROUP BY CUBE (one,2)` Note: Snowflake allows up to 7 elements (128 grouping sets) in each cube	BigQuery does not support a direct alternative to Snowflake's `GROUP BY CUBE`.

SELECT col1 as one, col2 as two

FROM table GROUP BY (one, 2)

SELECT col1 as one, col2 as two

FROM table GROUP BY (one, 2)

SELECT col1 as one, col2 as two

FROM table GROUP BY ROLLUP (one, 2)

SELECT col1 as one, col2 as two

FROM table GROUP BY ROLLUP (one, 2)

SELECT col1 as one, col2 as two

FROM table GROUP BY GROUPING SETS (one, 2)

Note: Snowflake allows up to 128 grouping sets in the same query block

BigQuery does not support a direct alternative to Snowflake's GROUP BY GROUPING SETS.

SELECT col1 as one, col2 as two

FROM table GROUP BY CUBE (one,2)

Note: Snowflake allows up to 7 elements (128 grouping sets) in each cube

BigQuery does not support a direct alternative to Snowflake's GROUP BY CUBE.

ORDER BY clause

There are some minor differences between Snowflake ORDER BY clauses and BigQuery ORDER BY clauses.

Snowflake		BigQuery
In Snowflake, `NULL`s are ranked last by default (ascending order).		In BigQuery, `NULLS` are ranked first by default (ascending order).
You can specify whether `NULL` values should be ordered first or last using `NULLS FIRST` or `NULLS LAST`, respectively.		There's no equivalent to specify whether `NULL` values should be first or last in BigQuery.

LIMIT/FETCH clause

The LIMIT/FETCH clause in Snowflake constrains the maximum number of rows returned by a statement or subquery. LIMIT (Postgres syntax) and FETCH (ANSI syntax) produce the same result.

In Snowflake and BigQuery, applying a LIMIT clause to a query does not affect the amount of data that is read.

Snowflake BigQuery

Snowflake	BigQuery
`SELECT col1, col2` `FROM table` `ORDER BY col1` `LIMIT count OFFSET start` `SELECT ...` `FROM ...` `ORDER BY ...` `OFFSET start {[ROW \| ROWS]} FETCH {[FIRST \| NEXT]} count` `{[ROW \| ROWS]} [ONLY]` Note: `NULL`, empty string (''), and $$$$ values are accepted and are treated as "unlimited". Primary use is for connectors and drivers.	`SELECT col1, col2` `FROM table` `ORDER BY col1` `LIMIT count OFFSET start` Note: BigQuery does not support `FETCH`. `LIMIT` replaces `FETCH`. Note: In BigQuery, `OFFSET` must be used together with a `LIMIT count`. Make sure to set the `count` INT64 value to the minimum necessary ordered rows for best performance. Ordering all result rows unnecessarily will lead to worse query execution performance.

SELECT col1, col2

FROM table

ORDER BY col1

LIMIT count OFFSET start

SELECT ...

FROM ...

ORDER BY ...

OFFSET start {[ROW | ROWS]} FETCH {[FIRST | NEXT]} count

{[ROW | ROWS]} [ONLY]

Note: NULL, empty string (''), and $$$$ values are accepted and are treated as "unlimited". Primary use is for connectors and drivers.

SELECT col1, col2

FROM table

ORDER BY col1

LIMIT count OFFSET start

Note: BigQuery does not support FETCH. LIMIT replaces FETCH.

Note: In BigQuery, OFFSET must be used together with a LIMIT count. Make sure to set the count INT64 value to the minimum necessary ordered rows for best performance. Ordering all result rows unnecessarily will lead to worse query execution performance.

QUALIFY clause

The QUALIFY clause in Snowflake allows you to filter results for window functions similar to what HAVING does with aggregate functions and GROUP BY clauses.

Snowflake BigQuery

Snowflake	BigQuery
`SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;`	The Snowflake `QUALIFY` clause with an analytics function like `ROW_NUMBER()`, `COUNT()`, and with `OVER PARTITION BY` is expressed in BigQuery as a `WHERE` clause on a subquery that contains the analytics value. Using `ROW_NUMBER()`: `SELECT col1, col2` `FROM ( SELECT col1, col2` `ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1;` Using `ARRAY_AGG()`, which supports larger partitions: `SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1) [OFFSET(0)] FROM table` `GROUP BY col1 ) AS result;`

SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;

The Snowflake QUALIFY clause with an analytics function like ROW_NUMBER(), COUNT(), and with OVER PARTITION BY is expressed in BigQuery as a WHERE clause on a subquery that contains the analytics value.

Using ROW_NUMBER():

SELECT col1, col2

FROM ( SELECT col1, col2

ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1;

Using ARRAY_AGG(), which supports larger partitions:

SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1) [OFFSET(0)] FROM table

GROUP BY col1 ) AS result;

Functions

The following sections list Snowflake functions and their BigQuery equivalents.

Aggregate functions

The following table shows mappings between common Snowflake aggregate, aggregate analytic, and approximate aggregate functions with their BigQuery equivalents.

Snowflake BigQuery

Snowflake	BigQuery
`ANY_VALUE([DISTINCT] expression) [OVER ...]` Note: `DISTINCT` does not have any effect	`ANY_VALUE(expression) [OVER ...]`
`APPROX_COUNT_DISTINCT([DISTINCT] expression) [OVER ...]` Note: `DISTINCT` does not have any effect	`APPROX_COUNT_DISTINCT(expression)` Note: BigQuery does not support `APPROX_COUNT_DISTINCT` with Window Functions
`APPROX_PERCENTILE(expression, percentile) [OVER ...]` Note: Snowflake does not have the option to `RESPECT NULLS`	`APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))]` Note: BigQuery does not support `APPROX_QUANTILES` with Window Functions
`APPROX_PERCENTILE_ACCUMULATE (expression)`	BigQuery does not support the ability to store intermediate state when predicting approximate values.
`APPROX_PERCENTILE_COMBINE(state)`	BigQuery does not support the ability to store intermediate state when predicting approximate values.
`APPROX_PERCENTILE_ESTIMATE(state, percentile)`	BigQuery does not support the ability to store intermediate state when predicting approximate values.
`APPROX_TOP_K(expression, [number [counters]]` Note: If no number parameter is specified, default is 1. Counters should be significantly larger than number.	`APPROX_TOP_COUNT(expression, number)` Note: BigQuery does not support `APPROX_TOP_COUNT` with Window Functions.
`APPROX_TOP_K_ACCUMULATE(expression, counters)`	BigQuery does not support the ability to store intermediate state when predicting approximate values.
`APPROX_TOP_K_COMBINE(state, [counters])`	BigQuery does not support the ability to store intermediate state when predicting approximate values.
`APPROX_TOP_K_ESTIMATE(state, [k])`	BigQuery does not support the ability to store intermediate state when predicting approximate values.
`APPROXIMATE_JACCARD_INDEX([DISTINCT] expression)`	You can use a custom UDF to implement `MINHASH` with `k` distinct hash functions. Another approach to reduce the variance in `MINHASH` is to keep `k` of the minimum values of one hash function. In this case Jaccard index can be approximated as following: `WITH` `minhash_A AS (` `SELECT DISTINCT FARM_FINGERPRINT(TO_JSON_STRING(t)) AS h` `FROM TA AS t` `ORDER BY h` `LIMIT k),` `minhash_B AS (` `SELECT DISTINCT FARM_FINGERPRINT(TO_JSON_STRING(t)) AS h` `FROM TB AS t` `ORDER BY h` `LIMIT k)` `SELECT` `COUNT(*) / k AS APPROXIMATE_JACCARD_INDEX` `FROM minhash_A` `INNER JOIN minhash_B` `ON minhash_A.h = minhash_B.h`
`APPROXIMATE_SIMILARITY([DISTINCT] expression)`	It is a synonym for `APPROXIMATE_JACCARD_INDEX` and can be implemented in the same way.
`ARRAY_AGG([DISTINCT] expression1) [WITHIN GROUP (ORDER BY ...)]` `[OVER ([PARTITION BY expression2])]` `Note: Snowflake does not support ability to IGNORE\|RESPECT NULLS and to LIMIT directly in ARRAY_AGG.`	`ARRAY_AGG([DISTINCT] expression1` `[{IGNORE\|RESPECT}] NULLS] [ORDER BY ...] LIMIT ...])` `[OVER (...)]`
`AVG([DISTINCT] expression) [OVER ...]`	`AVG([DISTINCT] expression) [OVER ...]` Note: BigQuery's `AVG` does not perform automatic casting on `STRING`s.
`BITAND_AGG(expression)` `[OVER ...]`	`BIT_AND(expression) [OVER ...]` Note: BigQuery does not implicitly cast character/text columns to the nearest `INTEGER`.
`BITOR_AGG(expression)` `[OVER ...]`	`BIT_OR(expression)` `[OVER ...]` Note: BigQuery does not implicitly cast character/text columns to the nearest `INTEGER`.
`BITXOR_AGG([DISTINCT] expression) [OVER ...]`	`BIT_XOR([DISTINCT] expression) [OVER ...]` Note: BigQuery does not implicitly cast character/text columns to the nearest `INTEGER`.
`BOOLAND_AGG(expression) [OVER ...]` Note: Snowflake allows numeric, decimal, and floating point values to be treated as `TRUE` if not zero.	`LOGICAL_AND(expression)` `[OVER ...]`
`BOOLOR_AGG(expression)` `[OVER ...]` Note: Snowflake allows numeric, decimal, and floating point values to be treated as `TRUE` if not zero.	`LOGICAL_OR(expression)` `[OVER ...]`
`BOOLXOR_AGG(expression)` `[OVER ([PARTITION BY <partition_expr> ])` Note: Snowflake allows numeric, decimal, and floating point values to be treated as `TRUE` if not zero.	For numeric expression: `SELECT` `CASE COUNT(*)` `WHEN 1 THEN TRUE` `WHEN 0 THEN NULL` `ELSE FALSE` `END AS BOOLXOR_AGG` `FROM T` `WHERE expression != 0` To use `OVER` you can run the following (boolean example provided): `SELECT` `CASE COUNT(expression) OVER (PARTITION BY partition_expr)` `WHEN 0 THEN NULL` `ELSE` `CASE COUNT(` `CASE expression` `WHEN TRUE THEN 1` `END) OVER (PARTITION BY partition_expr)` `WHEN 1 THEN TRUE` `ELSE FALSE` `END` `END AS BOOLXOR_AGG` `FROM T`
`CORR(dependent, independent)` `[OVER ...]`	`CORR(dependent, independent)` `[OVER ...]`
`COUNT([DISTINCT] expression [,expression2]) [OVER ...]`	`COUNT([DISTINCT] expression [,expression2]) [OVER ...]`
`COVAR_POP(dependent, independent) [OVER ...]`	`COVAR_POP(dependent, independent) [OVER ...]`
`COVAR_SAMP(dependent, independent)` `[OVER ...]`	`COVAR_SAMP(dependent, independent)` `[OVER ...]`
`GROUPING(expression1, [,expression2...])`	BigQuery does not support a direct alternative to Snowflake's `GROUPING`. Available through a User-Defined Function.
`GROUPING_ID(expression1, [,expression2...])`	BigQuery does not support a direct alternative to Snowflake's `GROUPING_ID`. Available through a User-Defined Function.
`HASH_AGG([DISTINCT] expression1, [,expression2])` `[OVER ...]`	SELECT `BIT_XOR(` `FARM_FINGERPRINT(` `TO_JSON_STRING(t))) [OVER]` FROM t
`SELECT HLL([DISTINCT] expression1, [,expression2])` `[OVER ...]` Note: Snowflake does not allow you to specify precision.	`SELECT HLL_COUNT.EXTRACT(sketch) FROM (` `SELECT HLL_COUNT.INIT(expression)` `AS sketch FROM table )` Note: BigQuery does not support `HLL_COUNT…` with Window Functions. A user cannot include multiple expressions in a single `HLL_COUNT...` function.
`HLL_ACCUMULATE([DISTINCT] expression)` Note: Snowflake does not allow you to specify precision.	`HLL_COUNT.INIT`(expression [, precision])
`HLL_COMBINE([DISTINCT] state)`	`HLL_COUNT.MERGE_PARTIAL`(sketch)
`HLL_ESTIMATE(state)`	`HLL_COUNT.EXTRACT(sketch)`
`HLL_EXPORT(binary)`	BigQuery does not support a direct alternative to Snowflake's `HLL_EXPORT`.
`HLL_IMPORT(object)`	BigQuery does not support a direct alternative to Snowflake's `HLL_IMPORT`.
`KURTOSIS(expression)` `[OVER ...]`	BigQuery does not support a direct alternative to Snowflake's `KURTOSIS`.
`LISTAGG(` `[DISTINCT] aggregate_expression` `[, delimiter]` `)` `[OVER ...]`	`STRING_AGG(` `[DISTINCT] aggregate_expression` `[, delimiter]` `)` `[OVER ...]`
`MEDIAN(expression) [OVER ...]` Note: Snowflake does not support ability to `IGNORE\|RESPECT NULLS` and to `LIMIT` directly in `ARRAY_AGG.`	`PERCENTILE_CONT(` `value_expression,` `0.5` [ {RESPECT \| IGNORE} NULLS] `) OVER()`
`MAX(expression) [OVER ...]` `MIN(expression) [OVER ...]`	`MAX(expression) [OVER ...]` `MIN(expression) [OVER ...]`
`MINHASH(k, [DISTINCT] expressions)`	You can use a custom UDF to implement `MINHASH` with `k` distinct hash functions. Another approach to reduce the variance in `MINHASH` is to keep `k` of the minimum values of one hash function: `SELECT DISTINCT` `FARM_FINGERPRINT(` `TO_JSON_STRING(t)) AS MINHASH` `FROM t` `ORDER BY MINHASH` `LIMIT k`
`MINHASH_COMBINE([DISTINCT] state)`	FROM ( SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TA AS t ORDER BY h LIMIT k UNION SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TB AS t ORDER BY h LIMIT k ) ORDER BY h LIMIT k
`MODE(expr1)` `OVER ( [ PARTITION BY <expr2> ] )`	`SELECT expr1` `FROM (` `SELECT` `expr1,` `ROW_NUMBER() OVER (` `PARTITION BY expr2` `ORDER BY cnt DESC) rn` `FROM (` `SELECT` `expr1,` `expr2,` `COUNTIF(expr1 IS NOT NULL) OVER` `(PARTITION BY expr2, expr1) cnt` `FROM t))` `WHERE rn = 1`
`OBJECT_AGG(key, value) [OVER ...]`	You may consider using `TO_JSON_STRING` to convert a value into JSON-formatted string
`PERCENTILE_CONT(percentile) WITHIN GROUP (ORDER BY value_expression)` `[OVER ...]`	`PERCENTILE_CONT(` `value_expression,` `percentile` [ {RESPECT \| IGNORE} NULLS] `) OVER()`
`PERCENTILE_DISC(percentile) WITHIN GROUP (ORDER BY value_expression)` `[OVER ...]`	`PERCENTILE_DISC(` `value_expression,` `percentile` [ {RESPECT \| IGNORE} NULLS] `) OVER()`
`REGR_AVGX(dependent, independent)` `[OVER ...]`	`SELECT AVG(independent) [OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)`
`REGR_AVGY(dependent, independent)` `[OVER ...]`	`SELECT AVG(dependent) [OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)`
`REGR_COUNT(dependent, independent)` `[OVER ...]`	`SELECT COUNT(*) [OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)`
`REGR_INTERCEPT(dependent, independent)` `[OVER ...]`	`SELECT` `AVG(dependent) -` `COVAR_POP(dependent,independent)/` `VAR_POP(dependent) *` `AVG(independent)` `[OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)` `[GROUP BY ...]`
`REGR_R2(dependent, independent)` `[OVER ...]`	`SELECT` `CASE` `WHEN VAR_POP(independent) = 0` `THEN NULL` `WHEN VAR_POP(dependent) = 0 AND VAR_POP(independent) != 0` `THEN 1` `ELSE POWER(CORR(dependent, independent), 2)` `END AS ...` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)` `[GROUP BY ...]`
`REGR_SLOPE(dependent, independent)` `[OVER ...]`	`SELECT` `COVAR_POP(dependent,independent)/` `VAR_POP(dependent)` `[OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)` `[GROUP BY ...]`
`REGR_SXX(dependent, independent)` `[OVER ...]`	`SELECT COUNT()VAR_POP(independent)` `[OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)` `[GROUP BY ...]`
`REGR_SYY(dependent, independent)` `[OVER ...]`	`SELECT COUNT()VAR_POP(dependent)` `[OVER ...]` `FROM table` `WHERE (` `(dependent IS NOT NULL) AND` `(independent IS NOT NULL)` `)` `[GROUP BY ...]`
`SKEW(expression)`	BigQuery does not support a direct alternative to Snowflake's `SKEW`.
`STDDEV([DISTINCT] expression)` `[OVER ...]`	`STDDEV([DISTINCT] expression)` `[OVER ...]`
`STDDEV_POP([DISTINCT] expression)` `[OVER ...]`	`STDDEV_POP([DISTINCT] expression)` `[OVER ...]`
`STDDEV_SAMP([DISTINCT] expression)` `[OVER ...]`	`STDDEV_SAMP([DISTINCT] expression)` `[OVER ...]`
`SUM([DISTINCT] expression)` `[OVER ...]`	`SUM([DISTINCT] expression)` `[OVER ...]`
`VAR_POP([DISTINCT] expression)` `[OVER ...]` Note: Snowflake supports the ability to cast `VARCHAR`s to floating point values.	`VAR_POP([DISTINCT] expression)` `[OVER ...]`
`VARIANCE_POP([DISTINCT] expression)` `[OVER ...]` Note: Snowflake supports the ability to cast `VARCHAR`s to floating point values.	`VAR_POP([DISTINCT] expression)` `[OVER ...]`
`VAR_SAMP([DISTINCT] expression)` `[OVER ...]` Note: Snowflake supports the ability to cast `VARCHAR`s to floating point values.	`VAR_SAMP([DISTINCT] expression)` `[OVER ...]`
`VARIANCE([DISTINCT] expression)` `[OVER ...]` Note: Snowflake supports the ability to cast `VARCHAR`s to floating point values.	`VARIANCE([DISTINCT] expression)` `[OVER ...]`

ANY_VALUE([DISTINCT] expression) [OVER ...]

Note: DISTINCT does not have any effect

ANY_VALUE(expression) [OVER ...]

APPROX_COUNT_DISTINCT([DISTINCT] expression) [OVER ...]

Note: DISTINCT does not have any effect

APPROX_COUNT_DISTINCT(expression)

Note: BigQuery does not support APPROX_COUNT_DISTINCT with Window Functions

APPROX_PERCENTILE(expression, percentile) [OVER ...]

Note: Snowflake does not have the option to RESPECT NULLS

APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))]

Note: BigQuery does not support APPROX_QUANTILES with Window Functions

APPROX_PERCENTILE_ACCUMULATE (expression)