BigQuery Graph is GA—and Google is turning graph context into an agent control plane

Google Cloud has made BigQuery Graph generally available, moving property-graph analysis into the warehouse rather than requiring teams to copy relational data into a separate graph database. The Sept. 1 release places ISO-standard Graph Query Language (GQL) beside SQL, keeps traversals under BigQuery’s row- and column-level security, and lets teams call BigQuery ML and AI functions from the same query environment.

For data-agent builders, the important change is not merely another query language. Google is packaging graph structure as a grounding layer: relationships among customers, products, suppliers, identities or events become explicit paths that an agent can traverse instead of reconstructing them from loosely related tables on every request.

Natural language can target SQL or GQL

BigQuery conversational analytics can now accept a question about a graph in natural language, use graph metadata such as descriptions and synonyms, translate the request into SQL or GQL, and visualize path-based answers. Google also says teams can connect Gemini Enterprise through an MCP server or publish a conversational data agent to it directly.

That gives enterprise teams a practical separation of concerns. Analysts can retain natural-language access, while the execution layer chooses the representation suited to the question: SQL for tabular aggregation and GQL for multi-hop relationships. The graph remains subject to the warehouse’s existing security controls rather than becoming a parallel data silo.

Google reports substantial engine improvements since preview: GQL runs twice as fast on public benchmarks, while undirected traversals are 100 times faster. The company did not identify the benchmark suite in the announcement, so those figures should be treated as vendor-reported rather than as an independent comparison.

One graph can cross catalog boundaries

The new “borderless lakehouse” design can define a virtual property graph across native BigQuery tables and open Iceberg tables exposed through Databricks Unity Catalog, AWS Glue or Snowflake. Google’s example connects customers stored on Google Cloud with product and supplier records in a Databricks catalog on AWS, then answers the relationship question with one GQL traversal and no copied dataset.

This is potentially useful for agent grounding because enterprise context rarely lives in one warehouse. It also raises an operational requirement: teams must test latency, permissions and metadata quality across every participating catalog, not just validate the natural-language interface.

Agent memory becomes queryable

Google’s most consequential addition is context graph in BigQuery Agent Analytics. The system shapes agent actions into a typed, queryable trace stored in BigQuery Graph: which option the agent chose, which policy applied and which alternatives it rejected. Outcomes can later be joined back to those decisions.

That turns observability into data a team can query. Instead of retaining only free-form traces, an operator can traverse the decision record to investigate why an agent acted and connect the answer to downstream results.

The GA label needs a qualifier. BigQuery Graph itself is generally available, but Google says parts of the surrounding agentic ecosystem are in preview or will roll out over the coming weeks. An agent skill for graph design is available through the Google Cloud Data Agent Kit; its ability to propose nodes and edges from datasets or diagrams and verify relationship match rates is still coming. Buyers should evaluate each component’s status separately before treating the full workflow as production-ready.