What changed
On September 1, Google announced that BigQuery Graph is generally available. It adds a property-graph layer over existing BigQuery tables and views: teams define node and edge tables in place, then traverse them with Graph Query Language (GQL) instead of exporting the data into a separate graph system.
The release matters because Google is shipping the graph and warehouse as one analytical surface. The BigQuery Graph overview describes interoperability between graph queries and SQL, ISO GQL and SQL/PGQ compatibility, and graph models that can be built without changing existing workflows or replicating the underlying data. Google also says the graph engine inherits BigQuery's scale and existing row- and column-level security, and can call BigQuery ML and AI functions in the same query.
Why this is an AI product change
Many enterprise questions are about paths, not rows: which supplier is behind a product, how money moved through an account network, or which services depend on a failing component. Those relationships are exactly where nested joins and recursive SQL become hard to read, maintain, and operate. A graph query can make the relationship itself the interface.
That changes the shape of an agent's grounding layer. A product can expose a narrow, typed operation such as “trace this customer's supply chain,” let BigQuery perform the multi-hop traversal, and then use SQL or an AI function to summarize the returned evidence. The GQL reference supports composable statements such as MATCH, FILTER, RETURN, and NEXT; the graph query guide also documents GRAPH_TABLE, which lets graph results flow back into ordinary SQL.
The cross-cloud example in Google's GA announcement is especially important for product teams. A virtual graph can map tables across environments and traverse relationships without first moving all of the data into a new database. That does not remove the need for governance—the agent still needs a constrained query surface, authorization, and an auditable result—but it reduces the amount of bespoke context plumbing required before a useful assistant can answer relationship-heavy questions.
What builders should do
Start with one relationship that already matters to a user journey: fraud rings, supplier dependencies, customer identity, incident blast radius, or service lineage. Define the nodes, edges, and stable keys from existing tables, then compare a graph query with the current join-based implementation. Measure traversal latency, slot consumption, result coverage, and whether the returned path is understandable enough to show as evidence.
Keep the agent interface smaller than the graph. A read-only tool that accepts a customer ID and returns a bounded set of verified paths is easier to secure and evaluate than giving a model arbitrary query generation. Return identifiers and relationship metadata alongside prose, and let the model explain the result rather than inventing the connection.
There are practical limits. BigQuery Graph uses capacity-based pricing; the documentation says GQL queries require Enterprise or Enterprise Plus reservations, while on-demand workloads can use the GRAPH_EXPAND function in SQL. Some surrounding agentic capabilities are still preview or rolling out, so teams should check the stage and edition requirements before committing to a production design.
The product takeaway
BigQuery Graph makes “add a knowledge graph” less of an infrastructure project and more of a data-modeling decision. For many AI products, the next useful context layer may already be sitting in the warehouse—hidden in the relationships between customers, events, assets, and services. The durable advantage will come from choosing which of those relationships deserve a typed, permissioned, evidence-producing tool.