BigQuery graph measures and GRAPH_EXPAND now GA

BigQuery's 10 November 2026 release makes graph measures generally available, along with the AGG function, a GRAPH_EXPAND function that now accepts multiple fact tables, and support for graphs and measures in Data Studio and Knowledge Catalog. The point is simple: you can define a calculation once, tie it to a key, and stop it from counting the same thing twice. The same release also brings the gemini-4-carbon model to BigQuery generative AI functions as a generally available option.

If your team has ever argued about why two dashboards disagree on the number of customers, this is the part of the release to read closely.

Key takeaways

• Graph measures, the AGG function and multi-fact GRAPH_EXPAND are generally available as of 10 November 2026.
• A measure locks an aggregation to a key, which targets the overcounting that happens when data is joined across tables.
• Extensions on labels and properties carry custom metadata for natural language querying, and measures and graphs are now cataloged in Knowledge Catalog automatically.
• The gemini-4-carbon model is generally available in BigQuery generative AI functions, and it deserves its own test before you change any production prompt.
• Pilot one disputed metric, compare it with a number you already trust, then widen the rollout.

What the 10 November 2026 release actually changed

There are two separate items in the notes, and they should not be blended together.

The larger one is about graphs and measures. You can now use graph measures to lock an aggregation to a key. Measure expressions can contain aggregate function calls, expressions inside aggregate functions, conditional logic inside aggregate functions, conditional distinct counting, scalar operations and expressions outside aggregate functions, and combinations of measures wrapped in the AGG function. To query a measure, you flatten your graph into a table with the GRAPH_EXPAND table-valued function and then call AGG on that table. GRAPH_EXPAND now supports multiple fact tables, and the BQ.SHOW_GRAPH_EXPAND_SCHEMA system procedure shows you the output schema.

Around that sit three supporting changes. You can define extensions in the OPTIONS clause of labels and properties, which are string pairs that act as custom metadata for natural language querying. Measures and graphs are supported in Data Studio through the BigQuery connector. And they are automatically cataloged in Knowledge Catalog, so people can find them by natural language or by domain synonyms. The notes state that these features are generally available.

The smaller item is that BigQuery generative AI functions now support the gemini-4-carbon model, also generally available.

Change	What it touches	Who cares most
Graph measures with AGG	Metric definitions	Analytics engineers, BI leads
GRAPH_EXPAND with multiple fact tables	Flattening graphs for querying	Data modelers
BQ.SHOW_GRAPH_EXPAND_SCHEMA	Debugging and documentation	Anyone writing queries on graphs
Extensions in OPTIONS	Natural language querying metadata	Teams using conversational analytics
Data Studio and Knowledge Catalog support	Reporting and discovery	Report authors, data governance
gemini-4-carbon model	Generative AI functions in SQL	Teams running AI functions in queries

Why overcounting is the problem worth solving

Overcounting is the quiet failure in most analytics stacks. You join an orders table to a line items table, then sum order value, and every order with three line items counts three times. Nobody sees an error. The number is just wrong, and it tends to be wrong in a direction that flatters the business.

Teams have patched this for years with careful subqueries, pre-aggregated tables and a lot of tribal knowledge. Each patch works until someone writes a new report and forgets the rule. The fix lives in a person's head, not in the model.

A measure that is locked to a key moves that rule into the definition. You say what the aggregation counts and which key it holds to, and the query layer is responsible for not multiplying it when other tables get joined in. That is the shift. It is less about a clever new function and more about where the logic lives.

The conditional distinct counting support matters here too. Think of a metric like customers who bought in the last quarter, counted once each no matter how many orders they placed. That is a conditional, distinct, key-bound aggregation, which is exactly the kind of thing that goes wrong in hand-written SQL.

One caution. A measure protects you from the overcounting you described to it. If the key is wrong, the answer is wrong in a more official-looking way. The modeling decision still belongs to a person who understands the business grain.

How GRAPH_EXPAND and AGG fit together

The query pattern has two steps, and it helps to keep them apart in your head.

First, GRAPH_EXPAND turns the graph into a flattened table. Think of it as the step that pulls the related pieces together into something you can query with ordinary SQL habits. Because it now supports multiple fact tables, a graph that models, say, both sales and support tickets around the same customers can be expanded without you forcing everything through one fact table.

Second, AGG evaluates a measure against that flattened table. You do not rewrite the aggregation inline. You ask for the measure by name, and the key-locking logic does the work.

A sensible first session looks like this:

1. Pick a graph that already exists, or define a small one around a single business area.
2. Run BQ.SHOW_GRAPH_EXPAND_SCHEMA to see exactly which columns GRAPH_EXPAND will give you.
3. Write one measure for a number your team already calculates by hand.
4. Query it with GRAPH_EXPAND and AGG, then compare the result with your existing figure.
5. Add a second fact table only after the first case reconciles.

The schema procedure deserves more attention than its name suggests. When a flattened table has columns from several fact tables, the first thing that goes wrong is a misunderstanding about what a column is. Reading the output schema before you write queries saves an afternoon of confusion, and it makes a decent artifact to paste into your documentation.

Extensions, Data Studio and Knowledge Catalog

The notes describe three changes that are really about who gets to use the model you build.

Extensions come first. In the OPTIONS clause of labels and properties you can define string pairs that serve as custom metadata for natural language querying. The notes do not spell out the keys or how they are used, so read the documentation for the exact syntax. What they are for is clear enough: a property called amt means little to a language model or a new analyst, while a short description and domain wording attached to it means a great deal. If you plan to let people ask questions in plain language, this is where you put the vocabulary of your business.

Data Studio support comes through the BigQuery connector. For a marketing analytics team, this is the practical bit. Report authors who are not SQL writers can work with measures and graphs instead of rebuilding aggregations in a chart's calculated field. That is where metric drift usually starts, so pulling the logic upstream is the real benefit.

Knowledge Catalog cataloging is automatic. Measures and graphs become searchable by natural language or domain synonyms. Your governance lead should hear about this early, because it means new assets will show up in search without anyone registering them. That is helpful for discovery and slightly alarming if your naming is sloppy. A measure called total_v2_final will be found just as easily as a good one.

A small piece of homework for each measure you publish:

• Give it a name a stranger could understand.
• Add extension metadata that uses the words your business actually uses.
• Record who owns it and which key it holds to.
• Decide which synonyms people will search for and check that search finds it.

The gemini-4-carbon model in generative AI functions

This is a one-line item in the notes, so keep the response proportionate. BigQuery generative AI functions now support the gemini-4-carbon model, and the model is generally available.

If you do not use those functions, there is nothing to do. If you do, for example to classify support tickets, extract fields from free text or summarise feedback inside SQL, the new model is an option you can evaluate. The notes say nothing about quality, cost or latency compared with other models, so do not assume any of those. Treat it as you would any model swap.

Take a fixed sample of real inputs, run it through the model you use today and through gemini-4-carbon, and have someone who knows the domain compare the outputs. Check the output format as well as the content, since downstream parsing is where silent breakage hides. Look at the pricing and quota pages in the official documentation before running anything at volume.

Do not change a scheduled production job on the strength of a release note. Add the new model beside the old one, compare, then decide.

Who should act, and what to do first

Not everyone needs to do something this week. Here is a plain split.

Role	Action	Urgency
Analytics engineer	Build one measure for a disputed metric and reconcile it	High if you have overcounting problems
BI or reporting lead	Test the Data Studio connector with a measure on a non-critical report	Medium
Data governance owner	Review naming and ownership before measures show up in Knowledge Catalog	Medium
Team using AI functions in SQL	Run a side-by-side test of gemini-4-carbon	Low to medium
Teams without graphs today	Read the documentation and decide whether graphs fit your model	Low

If you have no graph defined at all, you do not need to rush. Adopting graphs is a modeling decision, and a release note is a poor reason to restructure a warehouse that works. The people who should move first are those who already have a recurring argument about a number and a clear set of tables behind it.

Ignore the temptation to convert every metric at once. Pick the one that causes the most meetings.

Rolling out and testing without breaking trust

The worst outcome here is a new number that disagrees with the old one and no one can say which is right. Plan for that before it happens.

Run the measure in parallel with the existing calculation for at least one full reporting cycle. Keep both visible to a small group. When they differ, find out why before choosing a winner. Often the old number is the one that overcounted, and finding that out is a useful result in itself, though you will want to explain it to whoever reads the old report.

Test the edges on purpose. Use a customer with no orders, an order with no items, an order with an unusually large number of items, and records that fall outside your date filter. Overcounting hides in the cases that are not typical.

When you add a second fact table to GRAPH_EXPAND, test again from scratch. A measure that reconciled against one fact table has not been proven against two.

For measurement, track three things:

1. Reconciliation: does the measure match a trusted figure on a sample you can verify by hand?
2. Adoption: how many reports and queries use the measure instead of a local rewrite?
3. Disputes: how often does someone ask why two reports disagree? That count should fall.

Cost and runtime are worth watching too, but the notes give no figures, so measure your own queries before and after and look at the results rather than guessing.

Where a partner helps, and where you can manage alone

A competent in-house team can handle a first measure. The syntax is documented, the schema procedure shows you what you are getting, and a pilot on a single metric is a contained piece of work. If you have an analytics engineer who knows your tables, start there.

Outside help earns its fee in a few specific places. One is the modeling itself: deciding the grain of a graph, which keys matter, and how several fact tables relate. That is a design problem, and it is much cheaper to get right before forty reports depend on it. Another is governance across a large estate, where measures, catalog entries and natural language metadata need a convention that survives staff changes. A third is migration, when hundreds of calculated fields in reporting tools need to be traced back to a shared definition.

If you do bring someone in, brief them on the metric disputes you actually have, not on the feature list. A short written brief with sample tables, current definitions and the numbers that disagree will get better proposals than a general request. The RFP template helps you structure that, and the BigQuery partners page is a starting point for finding firms with relevant experience. If you want to weigh several firms side by side, the compare tool and the wider partner directory are there for that.

A few things not to do:

• Do not migrate every dashboard before one measure has proved itself.
• Do not publish measures with vague names and assume the catalog will sort it out.
• Do not swap the generative AI model in a production job without a side-by-side check.
• Do not treat the key choice as a detail. It is the decision the whole measure depends on.

The release is useful, and the useful part is narrow: a way to put metric logic in one governed place and stop it from inflating. Use it where that problem is real, test it against numbers you trust, and leave the rest of your warehouse alone until it earns a wider role. Confirm limits, syntax and any availability details in Google Cloud's own BigQuery documentation before you commit to a design.

Sources

• Google Cloud: BigQuery release notes, 10 November 2026 — Graph measures, GRAPH_EXPAND with multiple fact tables, BQ.SHOW_GRAPH_EXPAND_SCHEMA, extensions, Data Studio and Knowledge Catalog support, and gemini-4-carbon in generative AI functions.