Google’s BigQuery data agents are GA; database connectors are not

Google Cloud has moved BigQuery Conversational Analytics and the Conversational Analytics API into general availability, completing the production path from a governed data agent in BigQuery to a chat experience embedded in another application. Looker’s conversational analytics was already generally available; conversational analytics for AlloyDB, Cloud SQL and Spanner remains in preview. Google Cloud’s product update makes that support matrix explicit.

What is actually production-stage

The API can answer natural-language questions over structured data in BigQuery, Looker and Data Studio. It also exposes a QueryData route for AlloyDB, Spanner and Cloud SQL sources, but those database integrations should not be read as GA simply because the API itself is GA. Google’s current API overview separates the common agent surface from the maturity of each backing source.

For developers, the GA surface includes persistent or stateless conversations, saved agents, inline context, IAM policy operations and regional endpoints. Google says native SDKs cover Node.js, Java, Go, Python, PHP, Ruby and .NET, and the same agents can be embedded in custom applications or multi-agent systems through ADK and MCP. The company’s launch post also lists Lakehouse Managed Service tables, Apache Iceberg REST catalogs and federated AWS S3 Unity Catalogs among the reachable data estates.

The semantic work does not disappear

BigQuery’s product guidance still tells teams to supply table and field metadata, business instructions, glossaries and verified queries—the renamed “golden queries”—to encode approved SQL and business logic. Google warns that direct conversations without a configured data agent can be less accurate, and recommends views rather than asking the agent to infer joins. It also advises splitting agents when scope exceeds 20 data sources or crosses teams with different metric definitions. Those are important constraints for any team treating GA as a signal to widen access. BigQuery’s conversational analytics documentation documents those operating recommendations.

The runtime is read-only: Google says it respects source permissions and VPC Service Controls, cannot perform DML writes, cannot execute remote functions and only accesses explicitly selected knowledge sources. Location choices cover US, EU and global processing boundaries. BigQuery’s security and location guidance provides the current details.

Put cost rails in before rollout

Natural-language access still produces warehouse queries. For on-demand BigQuery billing, teams can set project and per-user daily quotas and configure big_query_max_billed_bytes so an oversized query fails after a dry-run estimate and before charges accrue. Google recommends isolating expensive agents in dedicated projects because per-agent quotas are not supported; the same controls do not apply to slot reservations. Google’s cost-control guide spells out those limits.

The takeaway is narrower—and more useful—than “chat with all enterprise data is GA.” Google now offers a supported API and BigQuery/Looker path for governed deployment, but database connectors, semantic preparation and spend isolation still need separate production decisions.