BigQuery Standard SQL vs Legacy SQL: What Is the Difference and Which Should You Use?

BigQuery Standard SQL, now called GoogleSQL, is the modern, ANSI-compliant dialect and the one you should use for every new query. Legacy SQL, sometimes just called BigQuery SQL, is the original dialect Google shipped in 2011 and has since deprecated. Standard SQL supports proper joins, common table expressions, window functions, arrays and structs, and it is the default in the BigQuery console today. If you are writing anything new, use Standard SQL. The only reason to touch Legacy SQL in 2026 is to maintain old queries that were never migrated.

The short version

BigQuery launched with a dialect that did not follow the SQL standard closely. In 2016 Google introduced Standard SQL to fix that, made it the default, and started steering everyone toward it. Standard SQL was later renamed GoogleSQL, but the meaning is unchanged: it is the current, supported, standards-based way to query BigQuery. Legacy SQL still runs, so old queries do not suddenly break, but Google has been clear that Standard SQL is where all new features land.

If you have inherited a warehouse with a mix of both, the practical rule is simple. Leave working Legacy queries alone until you have a reason to touch them, and write everything new in Standard SQL. Do not start a fresh project in Legacy SQL in 2026 under any circumstances.

The concrete differences

The two dialects look similar at a glance but differ in ways that will trip you up if you switch without knowing them. These are the ones that actually bite.

The comma difference is the most dangerous one. In Legacy SQL, listing two tables separated by a comma performs a UNION ALL, stacking their rows. In Standard SQL the exact same syntax performs a CROSS JOIN, multiplying rows together. A query copied from an old Legacy example into a Standard editor can silently return wildly different numbers, not an error. That is exactly the kind of quiet mistake that ends up in a report before anyone notices.

How to tell which dialect a query uses

BigQuery decides the dialect a few ways. In the modern console and the API, Standard SQL is the default. A query can force Legacy SQL by starting with the comment line that enables it, or by an explicit setting in older tools and scheduled queries. The fastest tell is the table syntax: square brackets and colons mean Legacy, backticks and dots mean Standard.

If you are auditing a warehouse, the migration is usually mechanical: swap the table references, replace the old type names, rewrite comma-unions as explicit UNION ALL, and confirm any functions still exist under the same name. Before you rewrite a shared query, it is worth knowing which dashboards and downstream jobs depend on it, so you do not fix the SQL and break a report nobody told you about. A tool that maps how a number flows from source to dashboard makes that check a lot less nerve-wracking.

Why this matters less than it used to

Here is the part worth stepping back for. The whole Standard-versus-Legacy question exists because you are writing SQL by hand, and hand-written SQL has to commit to a dialect, a set of type names, and a particular join syntax. Get any of those wrong for the engine you are on and you get either an error or, worse, a silently wrong answer.

Most people asking about BigQuery SQL dialects do not actually want to become dialect experts. They want an answer to a business question, and the dialect is an obstacle in the way of it. That is the gap we built Agentsql to close. You ask a question in plain English, it writes correct GoogleSQL for you, runs it read-only, and shows you the query it generated so you can check it. You never have to remember whether this table wants brackets or backticks, because the tool targets the current dialect every time.

Which should you use?

Use Standard SQL, now GoogleSQL, for everything. It is the default, it follows the SQL standard, it gets every new feature, and it is what Google supports. Reserve Legacy SQL for maintaining old queries you have not migrated yet, and migrate those when you get the chance. If you would rather skip the dialect question entirely, Agentsql connects read-only to BigQuery (as well as Postgres, MySQL and Snowflake), turns your plain-English question into correct SQL, and shows you the query every time. See how it works with BigQuery, read our guide to querying BigQuery without writing SQL, or watch how it works and ask your warehouse a question.