Legacy SQL feature availability

This document describes upcoming restrictions to BigQuery legacy SQL availability, which are based on usage during an evaluation period and take effect after June 1, 2026. These changes are part of BigQuery's transition away from legacy SQL to GoogleSQL, the recommended, ANSI-compliant dialect for BigQuery.

Migrating to GoogleSQL offers these benefits over legacy SQL:

• It can be more cost-effective, using the BigQuery advanced runtime for better performance.
• It lets you use features not supported by legacy SQL, such as DML and DDL statements, Common Table Expressions (CTEs), complex subqueries and join predicates, materialized views , search indexes , and Generative AI functions .

How feature availability works

BigQuery monitors the use of legacy SQL features during an evaluation period. For organizations and projects that don't use legacy SQL between November 1, 2025, and June 1, 2026, legacy SQL becomes unavailable after the evaluation period ends. For organizations and projects that use legacy SQL during the evaluation period, you can continue to run queries using the specific set of legacy SQL features that you use.

Feature usage is aggregated at the organization level. If any project within an organization uses a feature, that feature remains available to all other projects in the organization. For projects not associated with an organization, feature availability is managed at the project level.

Legacy SQL feature sets

Legacy SQL capabilities are organized into three feature sets: basic language capabilities, extended language capabilities, and function groupings. The following sections detail the features within each set.

Basic language capabilities

These features are the core of legacy SQL. This entire feature set is available to any organization or stand-alone project that runs at least one legacy SQL query during the evaluation period.

Extended language capabilities

This category includes specific legacy SQL features that go beyond the basic set. Unlike basic capabilities or function groupings, each feature in this category is tracked individually. You must explicitly use each feature during the evaluation period for it to remain available.

Function groupings

Built-in functions are organized into related categories. Using any single function within a grouping during the evaluation period makes all functions in that entire grouping available.

Examples of feature availability

The following examples demonstrate how feature availability works.

Example: Accessing basic language capabilities

A project runs a legacy SQL query during the evaluation period. Assume table T contains a column X of type INTEGER .

  # 
 legacySQL 
 SELECT 
  
 X 
  
 FROM 
  
 T 
 

This usage ensures that all projects within the organization retain the ability to run queries that use any feature from the basic language capabilities set. For example, the following query continues to work:

  # 
 legacySQL 
 SELECT 
  
 X 
  
 FROM 
  
 T 
  
 WHERE 
  
 X 
 > 
 10 
 

Example: Using function groupings

A project uses one function from a specific function grouping. Assume table T contains a column X of type FLOAT .

  # 
 legacySQL 
 SELECT 
  
 SIN 
 ( 
 X 
 ) 
  
 FROM 
  
 T 
 

The use of the SIN() function makes the entire mathematical functions grouping available. Consequently, all projects within the organization can use any other function from that grouping, such as COS() .

  # 
 legacySQL 
 SELECT 
  
 COS 
 ( 
 X 
 ) 
  
 FROM 
  
 T 
 

Conversely, the following query fails after the evaluation period if no project in the organization uses any function from the aggregate functions for statistics grouping.

  # 
 legacySQL 
 SELECT 
  
 STDDEV 
 ( 
 X 
 ) 
  
 FROM 
  
 T 
 

Example: Feature retention across different tables

Assume table X has a column A ( INTEGER ) and table Y has column B ( FLOAT ). A project runs the following query during the evaluation period:

  # 
 legacySQL 
 SELECT 
  
 SIN 
 ( 
 A 
 ) 
  
 FROM 
  
 X 
 

The organization can run the following query after the evaluation period ends. The query works because the mathematical functions feature was retained by the first query. The retention is independent of the specific table, column name, or data type used, as both INTEGER and FLOAT are part of the basic language capability.

  # 
 legacySQL 
 SELECT 
  
 COS 
 ( 
 B 
 ) 
  
 FROM 
  
 Y 
 

Example: Complex query

Assume table T contains a column X of type STRING . A project runs the following query during the evaluation period:

  # 
 legacySQL 
 SELECT 
  
 value 
 , 
  
 AVG 
 ( 
 FLOAT 
 ( 
 value 
 )) 
  
 OVER 
  
 ( 
 ORDER 
  
 BY 
  
 value 
 ) 
  
 AS 
  
 avg 
  
 FROM 
  
 ( 
  
 SELECT 
  
 LENGTH 
 ( 
 SPLIT 
 ( 
 X 
 , 
  
 ',' 
 )) 
  
 AS 
  
 value 
  
 FROM 
  
 T 
 ) 
 

This query uses features from the basic language capabilities and three function groupings: basic window functions, string functions, and functions returning repeated values. All projects within the organization retain these features. Therefore, a new query that uses a different combination of functions from those same retained feature sets succeeds.

  # 
 legacySQL 
 SELECT 
  
 value 
 , 
  
 COUNT 
 ( 
 STRING 
 ( 
 value 
 )) 
  
 OVER 
  
 ( 
 ORDER 
  
 BY 
  
 value 
 ) 
  
 as 
  
 count 
  
 FROM 
  
 ( 
  
 SELECT 
  
 CONCAT 
 ( 
 SPLIT 
 ( 
 X 
 , 
  
 ',' 
 ), 
  
 '123' 
 ) 
  
 AS 
  
 value 
  
 FROM 
  
 T 
 ) 
 

Frequently asked questions

Can a new organization use legacy SQL?

Following the evaluation period, legacy SQL isn't available for new organizations or projects. In special cases, you can request an exemption . If you're unable to access Google Forms, instead email bq-legacysql-support@google.com with your organizational ID, current usage levels, recent usage date, migration challenges, and an estimated timeline for transitioning to GoogleSQL.

Do existing legacy SQL queries stop working?

Existing queries will continue to work as long as all the legacy SQL features they use were used by at least one project in your organization during the evaluation period. A query might fail if it relies on a feature that was not used during this period, so we recommend that you ensure all critical queries are run.

Can an existing organization that uses legacy SQL create new projects that also use it?

Yes. All features that any project in your organization accessed during the evaluation period remain available to all projects, old and new, in your organization.

Is there a tool to check which legacy SQL features my organization uses?

There isn't a tool to audit specific feature usage. You can track legacy SQL usage by querying INFORMATION_SCHEMA.JOBS views as described in Legacy SQL query jobs count per project . You can also review your query logs in Cloud Logging to check for specific syntax usage.

Do I have to migrate to GoogleSQL?

Migration isn't required, but it is encouraged. GoogleSQL is the modern, fully-featured, and recommended dialect.

What if a rarely used legacy SQL query does not run during the evaluation period?

To ensure that a query continues to work, run it once during the evaluation period. If you're unable to run it then, you can request an exemption . If you're unable to access Google Forms, instead email bq-legacysql-support@google.com with your organizational ID, current usage levels, recent usage date, migration challenges, and an estimated timeline for transitioning to GoogleSQL.

What's next

• To migrate your queries from legacy SQL to GoogleSQL, see the migration guide .