Breakthroughs

Google Agentic Data Cloud: What Google’s Lake

Google's Agentic Data Cloud brings BigQuery to S3 and Azure without egress fees. What that means for Databricks' 2026 decision in the DACH region.

By Alec Chizhik May 3, 2026 6 min read

Google Agentic Data Cloud: What Google’s Lake

Google bundles BigQuery, AlloyDB, Spanner and Apache Spark under one name and calls the result Agentic Data Cloud. That sounds like marketing. It gets concrete once you take a closer look at the cross-cloud lakehouse announcement: BigQuery can now query Iceberg tables on Amazon S3 without egress fees, over Google’s own Cross-Cloud Interconnect lines. Behind the feature announcement sits a pricing argument against Databricks.

Key takeaways

Cross-Cloud Lakehouse without egress: BigQuery reads and writes Iceberg tables on AWS S3 and Azure Data Lake Storage, with no egress fees thanks to Cross-Cloud Interconnect. No data moves, no copies, no paying twice.
Bidirectional Catalog Federation: Databricks Unity Catalog, Snowflake Polaris and AWS Glue are now federated. Engines read and write directly in each other’s catalog. Zero-copy sharing without ETL.
Migration in around 9 months: Google puts the average for cloud-to-cloud migrations at nine months – well below the multi-year timeframe communicated so far.
Managed Iceberg GA: BigQuery Lakehouse is generally available with automatic table management, multi-table transactions, change data capture and history-based optimizations.

What Google means by Agentic Data Cloud

Google positions BigQuery, AlloyDB, Spanner and Apache Spark as a unified platform against Databricks and Snowflake. The announcements from Google Cloud Next 2026 show in detail what this means in practice for DACH architectures.

What is the Google Agentic Data Cloud? It is the strategic umbrella over AlloyDB, BigQuery, Spanner, Bigtable and the Managed Apache Spark Service. The goal: make enterprise data available as context for autonomous AI agents, going beyond reports prepared for human analysts. At the center sits a “Universal Context Engine” – a layer that keeps agents from hallucinating for lack of access to the right company data.

This is technically consistent thinking. Agentic workflows need real-time data access instead of static reports – read and write, across system boundaries. Until now, that was the argument for Databricks: an open, Spark-based platform that can in principle talk to anything. Google is now trying to devalue that argument.

In concrete terms: Gemini-based agents in Vertex AI can access BigQuery directly, without manual ETL pipelines. The BigQuery Cortex Framework speeds this up with prebuilt connectors for SAP, Salesforce and Oracle. That sounds like an off-the-shelf catalog solution – yet the breadth of the integrations and the depth of the tie-in to GCP are genuinely new.

Cross-Cloud Lakehouse: the real attack

The part that will matter in Databricks customer conversations is the Cross-Cloud Lakehouse, much more than the agentic branding. BigQuery can now read and write Iceberg tables that physically reside on Amazon S3 or Azure Data Lake Storage. The connection runs over Cross-Cloud Interconnect – a dedicated private line with no public internet and no egress fees.

This matters because it overturns the data egress argument. Until now, a BigQuery migration was often expensive because data had to be moved out of S3 or Azure. Anyone running Databricks on AWS today who wants to test BigQuery at least in parallel no longer has to plan for large data transfers. The lakehouse stays on S3 and BigQuery accesses it directly.

Figures for context

American Express is migrating a central on-premises data warehouse plus several hundred production applications to BigQuery for agent-based commerce platforms
Around 9 months is what Google cites as the average migration time for cloud-to-cloud moves – multi-year projects used to be the norm
6 catalog partners federated: AWS Glue, Databricks Unity Catalog, Snowflake Polaris, SAP, Salesforce and Confluent Tableflow (coming soon)
Managed Iceberg GA since April 2026: multi-table transactions, CDC and history-based optimizations in BigQuery Lakehouse

Catalog Federation and the Databricks bone of contention

Catalog Federation is the second big lever. Google has announced bidirectional federation for Databricks Unity Catalog, Snowflake Polaris and AWS Glue. Engines can write to and read from each other’s catalog directly – without data copies and without ETL pipelines in between. Zero-copy sharing.

For DACH companies that already run Databricks and wonder whether BigQuery fits certain workloads better, this is a different conversation than twelve months ago. You no longer have to choose. You can start shifting workloads selectively while the data foundation stays on S3 or in Databricks.

“Migration is no longer a multi-year project. Cloud-to-cloud moves take nine months on average today. The question has moved from whether to which workload goes first.”

Google Cloud, Google Cloud Next 2026, April 2026

BigQuery Lakehouse vs. Databricks for DACH architectures

In DACH enterprise environments, the discussion usually runs along three axes: governance and data sovereignty, total cost of ownership and integration with existing SAP landscapes. Google has addressed all three directly.

BigQuery Lakehouse

Serverless, no cluster management
Built-in Gemini integration without extra connectors
Managed Iceberg with multi-table transactions
SAP Cortex connectors out of the box
Cross-cloud without egress costs (preview)

Databricks

Deeper Spark ML workflows for data scientists
Unity Catalog as a mature open standard
MLflow, Delta Lake and Mosaic AI deeply integrated
Stronger in multi-cloud setups without GCP dependency
Broader ecosystem independence

Anyone building mainly analytics, BI and agent context in the GCP ecosystem now gets a serious argument with BigQuery Lakehouse. Anyone running Spark-based machine learning workflows with data science teams and wanting to stay cloud-agnostic still holds the better cards with Databricks.

What this means for the 2026 decision

The context has changed. Anyone who said in 2024 “we’re staying on Databricks because switching to BigQuery costs too much” should take note: the egress argument only holds to a limited extent once Cross-Cloud Lakehouse is available in your own region. Data movement drops out as the main cost item.

What remains are the real questions: Which workloads sit close to GCP? Where do we run machine learning beyond analytics? How deep is our SAP integration? These answers now decide the matter, and the egress tariff no longer does.

For DACH architects, this means the next data platform tender is worth recalibrating. The reason is that Google Cloud Next 2026 has shifted the basis for comparison, which does not automatically make BigQuery the better choice. Databricks will respond. The rest of the year will show how.

Frequently Asked Questions

What is Google Agentic Data Cloud and how does it differ from previous BigQuery offerings?

Agentic Data Cloud is Google’s strategic umbrella over AlloyDB, BigQuery, Spanner, Bigtable and Managed Apache Spark. The difference from previous BigQuery offerings lies in the focus: a shift from human analysis toward machine data consumption by AI agents. As a new layer, the Universal Context Engine is meant to prevent hallucinations by giving agents direct, structured access to company data.

How does Cross-Cloud Lakehouse work without egress fees on a technical level?

BigQuery uses Cross-Cloud Interconnect to access Iceberg tables that physically reside on Amazon S3 or Azure Data Lake Storage. Cross-Cloud Interconnect is a dedicated private line between Google and the other hyperscalers – no public internet and therefore no egress costs. Queries run like native BigQuery queries while the tables sit on third-party infrastructure.

What does Catalog Federation mean for existing Databricks installations?

Catalog Federation enables bidirectional connections between BigQuery and Databricks Unity Catalog. Engines on both sides can read and write directly, without data copies or ETL pipelines. For companies with existing Databricks installations, this means BigQuery can serve selected analytics workloads without touching the Databricks data foundation.

Is Google right that migrations now take only nine months?

Google communicates nine months as the average for cloud-to-cloud migrations. The figure refers to pure data migration using Google’s migration tools and assessment tooling for Databricks workloads. The nine-month figure sounds convincing, yet it should be checked against your own complexity profile: SAP integration, existing ML pipelines and governance requirements can take considerably more time.

For which DACH companies does a switch to BigQuery Lakehouse make sense today?

It makes sense mainly for companies that already work heavily in the GCP ecosystem and can separate analytics workloads from Spark-based ML workflows. Large SAP landscapes benefit from the Cortex connectors. Companies with data science teams that have deep Spark expertise and run Databricks MLflow workflows have no compelling reason to switch – federation now allows coexistence instead of an either/or choice.