BigQuery column aliases and cross-region table copy now GA

Google made three BigQuery features generally available on 15 October 2026: copying tables across regions, column aliases in GoogleSQL, and exporting a conversational analytics agent's answer to PDF or CSV. The alias feature is opt-in only, so it does nothing until someone on your team turns it on. For most teams the practical work is deciding who owns each of the three and where the limits sit.

Key takeaways

• Three features reached general availability on 15 October 2026: cross-region table copy, column aliases in GoogleSQL, and PDF or CSV export of a conversational analytics agent's answer.
• Column aliases must be enabled first. Nothing changes in your queries until someone does that, so give the switch an owner and a test plan.
• An alias defined in the SELECT clause can be reused in the same SELECT list and in the WHERE clause of the same query block. That removes many wrapper subqueries and repeated expressions.
• Cross-region table copy is a normal operation now, but where data may live is still a governance question. Check residency rules and Google's pricing documentation first.
• Exported agent answers carry text, visualizations, tables and citations. Decide who may export, and what a recipient should treat as verified.
• Most teams can adopt all three without outside help. A partner pays for itself on migrations, multi-region designs and governance, not on a settings change.

What column aliases in GoogleSQL change in a query

The release notes describe the feature in one sentence: you define an alias for an expression in the SELECT clause and immediately reference it within the same SELECT list or in the WHERE clause of the same query block.

If you write GoogleSQL daily, you know why that matters. Until now, an alias defined in a SELECT list generally could not be used by the next column in that same list. You either repeated the expression or wrapped the query in a subquery or common table expression just to give the alias somewhere to live. Take a campaign report that computes spend / NULLIF(clicks, 0) as cost per click, then needs a second column that compares cost per click to a target. Without aliases, that long expression appears twice, and somebody eventually edits one copy and forgets the other.

With the feature enabled, you define cost per click once and refer to it by name. The same goes for filtering. A filter on a derived value, such as a session count built from a conditional expression, can name the alias in WHERE instead of restating the logic.

The gain is readability and fewer chances for two copies of a formula to drift apart. It is not a performance feature, and the notes don't claim one. Don't expect query cost or speed to move because you tidied your SQL. Judge it as a maintenance improvement.

The notes add a second purpose. Column aliases streamline migrating workloads from other data warehouses such as Snowflake and Teradata, because the feature supports their syntax. That is all the notes say on the subject. They don't describe how queries on those platforms are written, and neither should you assume anything beyond what the feature's documentation lists. If you have a migration in flight, the useful step is to take a few real queries from the source system, run them with aliases enabled, and record which ones now translate with less rewriting. That tells you how much the feature saves on your estate, which no release note can.

Why opt-in changes how you roll it out

The notes say the feature is generally available and opt-in only, and that you must first enable it. They don't say why, and there's no need to guess. What matters is the operational consequence: nothing happens by default, so adoption is a decision somebody has to make and own.

That sounds trivial and is where these things go wrong. A feature that needs enabling gets enabled by one engineer in one project, and the next engineer in a different project writes a query that depends on it and finds it fails. Shared SQL, saved queries, scheduled queries and dbt-style model code can then behave differently depending on where they run.

A sensible rollout looks like this:

1. Read the enablement instructions in Google's documentation and note the scope at which the setting applies.
2. Enable it in a development or sandbox project first.
3. Run your existing test queries and scheduled workloads there. They should return the same results as before. Treat any difference as a finding to explain, not a surprise to absorb.
4. Write down which environments have it on, and make that list part of your onboarding notes for analysts.
5. Only then enable it where production queries run, and tell the people who author SQL.

One rule worth setting early: don't let new shared code depend on aliases in an environment where the feature is off. Decide as a team whether alias reuse is allowed in production models yet, and put that in your SQL style guide in one line.

Copying tables across regions is now a standard operation

The notes are brief here: you can copy tables across regions, and the feature is generally available. They give no further detail, so the specifics of supported scenarios and any constraints belong to Google's documentation, not to this post.

What the feature is for is easy to explain. BigQuery datasets live in a location, and teams end up with data in more than one. A US dataset built early, an EU dataset added for a regional business, an asia-southeast dataset created because a stakeholder asked. When a table needs to exist somewhere else, whether for a join, for a regional copy of a reference table or for a migration between regions, teams have often built their own export and load pipeline to get it there. A generally available copy operation means a supported route rather than a bespoke one.

General availability does not settle whether you should copy. Three questions come first.

• Is the data allowed to leave its region? If a table holds personal data tied to a residency commitment, a technical ability to copy it is not permission. Your legal or privacy lead decides, and the answer goes in writing before any scheduled job is created.
• What does it cost? The notes say nothing about pricing. Check Google's pricing documentation and run a small test before you schedule recurring copies of large tables. Don't build a cost model from assumptions.
• Who is the owner of the copy? A copy is a second source of truth the moment it exists. Decide whether it is refreshed, how often, and what a consumer should do when it is stale.

For a team consolidating regions, the feature may simplify the mechanics of a move. It does not do the harder work of deciding which datasets go where, which permissions and downstream jobs have to change, and when the old location is switched off. That planning is where a multi-region estate gets messy.

Exporting a conversational analytics agent's answer

The third change concerns conversational analytics agents. You can export an agent's answer, including text, visualizations, tables and citations, to a PDF or CSV file. The feature is generally available.

The obvious use is the one business users will find in a week: someone asks the agent a question, gets an answer they like, and wants to drop it into a deck or an email. Until export existed, that meant screenshots and copy-paste. Now the answer, with its citations, leaves the tool as a file.

That is useful, and it is also the point to think about governance. An exported file is detached from the conversation that produced it. It no longer carries the context of how the question was phrased, or the fact that an agent summarised data rather than an analyst reviewing it. Citations in the export help, because a reader can see what the answer leaned on. They don't make the answer correct.

Some practical rules that cost almost nothing:

• Treat an exported CSV as a working file, not a report. If a number goes into a board pack, an analyst reruns it from the source tables.
• Decide which agents are used for exploration and which are used for answers people will circulate. The second group deserves more review of how the agent is configured.
• Put the export date on anything that is shared. A PDF has no way to tell its reader that the underlying data has since changed.
• Check who can see the underlying data. An export moves content to wherever the recipient keeps files. Confirm in the documentation how access controls apply to what the agent returns.

If your organisation has not yet put conversational analytics in front of business users, this release is a reason to define the sharing rules before it happens.

Who should act, and what to do

Not every change needs attention from every team. The table below sorts the three by who it touches and the first sensible step.

Change	Who it affects most	First action	Owner
Column aliases in GoogleSQL (GA, opt-in)	Analysts, analytics engineers, anyone maintaining shared SQL	Enable in a sandbox, rerun existing queries, then decide on a production policy	Analytics engineering lead
Cross-region table copy (GA)	Data platform owners, teams with datasets in more than one region	Confirm residency rules, test a small copy, check pricing documentation	Data platform lead with privacy or legal
Export of conversational analytics answers to PDF or CSV (GA)	Business users, the team that configures agents	Write sharing rules; decide which exports need analyst review	Analytics or BI lead

If you can only do one thing this month, make it the alias decision. It touches the most people, and the longer it stays undecided, the more inconsistent your SQL gets. If you have a migration from another warehouse underway, move it to the front of the list, because that is where the notes say the feature helps.

How to test and measure the changes

None of these three needs a long project. Each needs a short, deliberate test so you know what you gained.

For aliases, pick ten to twenty real queries, the ones with the longest repeated expressions or the most nested subqueries. Rewrite them with aliases and compare the results row for row against the originals. Then count what actually changed: lines of SQL, nesting depth, and how many places a business rule is now defined. If you are migrating from Snowflake or Teradata, add a column to your tracking sheet for queries that needed fewer edits to run. Those figures are yours, so you can report them honestly.

For cross-region copy, test with a small, non-sensitive table first. Record how long it takes, what it costs, and what the destination table looks like compared to the source. Then try the failure paths: what happens to a scheduled job when the source table changes shape, and who is told.

For agent exports, sit with two or three business users and watch what they export and where it goes. You are looking for the gap between what the file says and what the reader will assume it means. Fix that with a footer, a naming convention or a short guideline, not with a policy document nobody reads.

Across all three, keep the measures simple. Fewer duplicated expressions, fewer ad hoc pipelines, fewer screenshots in circulation. Don't invent a return-on-investment figure for a release this small.

What not to do

A few mistakes are predictable.

Don't enable column aliases everywhere on the day you read the notes. The feature is opt-in for a reason you can ignore but a consequence you can't: an environment where it is on and one where it is off will treat the same SQL differently. Stage it.

Don't rewrite your whole SQL estate to use aliases. Old queries that work are not a problem. Apply the new style to code you are already touching.

Don't treat cross-region copy as a replacement for a data residency design. It moves tables. It does not tell you which tables should move.

Don't assume a copy is free or instant because the operation is generally available. The notes don't speak to either, so measure.

Don't let exported agent answers become the record of what the business believes. A PDF with citations is easier to forward than to verify, and people forward things.

And don't read more into the notes than they say. Where this post says to check Google's documentation, it means it: limits, supported configurations and pricing details live there.

Where a partner helps, and where you can manage alone

For the alias change, you likely don't need anyone. It's a setting, a test and a style-guide line. A competent analytics engineer can do it in an afternoon and the rest is team discipline.

Cross-region copy sits in the middle. A single table copy is a small task. A programme to consolidate or split regions, with permissions, scheduled jobs, downstream dashboards and residency sign-off, is a project, and teams that have done it before save real time. If that describes your situation, look at BigQuery implementation partners and compare how they handle multi-region work, or browse the wider list of Google data analytics partners if your scope reaches past BigQuery itself.

A migration from another warehouse is the strongest case for outside help. The alias feature may reduce rewriting, but a migration is mostly about data modelling, validation, cut-over and people, and the SQL dialect is a small part of that. If you go to market for a partner, write the brief first. Our RFP template is a reasonable starting point: it pushes you to state your source systems, regions, data volumes and success measures, which is what separates a useful proposal from a generic one.

Conversational analytics governance is newer ground. Few partners have deep experience of it yet, so ask for specifics: which agents they have configured, how they handled review of answers, and what they advise about sharing. Be wary of anyone who treats export as a pure convenience feature.

For wider reading on how to choose and brief a partner, see the MarTech Partners blog.

The short version: switch aliases on carefully, treat region copies as a governance matter before a technical one, and write the sharing rules for agent exports before your users write them for you.

Sources

• Google Cloud: BigQuery release notes, 15 October 2026 — Cross-region table copy GA, column aliases in GoogleSQL (GA, opt-in), and export of conversational analytics agent answers to PDF or CSV (GA).