BigQuery adds two Canadian data-agent regions—but mixed-region sources can still send an agent global

Google Cloud has added Montréal (northamerica-northeast1) and Toronto (northamerica-northeast2) to the supported locations for conversational analytics in BigQuery. The October 16 release note is short, but the location rules behind it make this more than a regional availability update: they determine where agent and conversation resources are stored and where machine-learning processing occurs. Google Cloud release notes Conversational analytics locations

The source map chooses the default

When all knowledge sources belong to one supported region, BigQuery uses that region. Sources distributed across US regions default to the US multi-region endpoint, and sources distributed across EU regions default to the EU multi-region endpoint. Other combinations default to the global location. Teams can choose a different supported location while creating the agent, but Google says that location cannot be changed after the agent is saved. Conversational analytics locations

That creates a concrete pre-deployment review: inventory every table, view, graph and function the agent will use; calculate the default location from that inventory; then decide whether the result satisfies the organization’s processing and storage requirements. Adding a source from another jurisdiction later should trigger the same review rather than being treated as an ordinary metadata change.

The rollout does not move existing agents automatically. Google says agents created before June 4, 2026 remain in the global location. Because an agent’s location is immutable after saving, teams that need a regional placement should plan for creating and validating a replacement rather than expecting an in-place switch. Conversational analytics locations

“Available in Canada” is not a universal Gemini residency promise

Google’s broader Gemini-in-BigQuery location documentation distinguishes jurisdictional processing from individual-location residency. It says Gemini in BigQuery generally does not provide residency for individual locations; supported GA features can constrain processing to US or EU jurisdictions, while processing outside those jurisdictions may be global. It also documents feature-specific behavior—for example, SQL assistance, the Data Engineering Agent and data preparation do not all derive location in the same way. Gemini in BigQuery processing locations

The practical consequence is to review each Gemini feature separately. The new Montréal and Toronto entries explicitly govern BigQuery conversational analytics agents and conversations. They should not be used as evidence that every Gemini-assisted workflow in the same project inherits the same city-level processing or storage behavior.

For Canadian deployments, the clean rollout is therefore: create a test agent with sources confined to the intended region, verify its recorded location before sharing it, run representative verified queries, and document the source-location rule alongside the agent configuration. Regional availability removes one blocker; it does not remove the need to model where every connected source makes the agent run.