{"id":39066,"date":"2026-05-03T11:51:26","date_gmt":"2026-05-03T09:51:26","guid":{"rendered":"https:\/\/www.cloudmagazin.com\/2026\/05\/03\/google-agentic-data-cloud-bigquery-lakehouse-databricks-dach\/"},"modified":"2026-05-03T11:51:26","modified_gmt":"2026-05-03T09:51:26","slug":"google-agentic-data-cloud-bigquery-lakehouse-databricks-dach","status":"publish","type":"post","link":"https:\/\/www.cloudmagazin.com\/en\/2026\/05\/03\/google-agentic-data-cloud-bigquery-lakehouse-databricks-dach\/","title":{"rendered":"Google Agentic Data Cloud: What Google’s Lake"},"content":{"rendered":"

9 min. read<\/p>\n

Google is bundling BigQuery, AlloyDB, Spanner, and Apache Spark under one name, calling the result Agentic Data Cloud. That sounds like marketing. But it becomes concrete when you take a closer look at the cross-cloud lakehouse announcement: BigQuery can now query Iceberg tables on Amazon S3 without egress fees, via Google’s own Cross-Cloud Interconnect lines. This isn’t a feature announcement. This is a pricing argument against Databricks<\/p>\n

Cross-Cloud Lakehouse: the real offensive<\/h2>\n

The part that becomes relevant in Databricks customer conversations is not the agentic branding. It is the Cross-Cloud Lakehouse. BigQuery can now read and write Iceberg tables that are physically located on Amazon S3 or Azure Data Lake Storage. The connection runs via Cross-Cloud Interconnect – a dedicated private line, no public internet, no egress fees.<\/p>\n

This is significant because it overturns the data egress argument. Previously, a BigQuery migration was often expensive because data had to be moved out of S3 or Azure. Those who currently operate Databricks on AWS and want to test BigQuery at least in parallel no longer need to plan for large data movements. The Lakehouse resides on S3, BigQuery accesses it directly.<\/p>\n

\n

Key Figures<\/p>\n

    \n
  • American Express<\/strong> is migrating a central on-premises data warehouse as well as several hundred production applications to BigQuery for agent-based commerce platforms<\/li>\n
  • Google states around 9 months<\/strong> as the average migration duration for cloud-to-cloud transitions – previously, multi-year projects were the standard<\/li>\n
  • 6 Catalog Partners<\/strong> federated: AWS Glue, Databricks Unity Catalog, Snowflake Polaris, SAP, Salesforce, and Confluent Tableflow (coming soon)<\/li>\n
  • Managed Iceberg GA<\/strong> since April 2026: Multi-Table Transactions, CDC, and History-Based Optimizations in BigQuery Lakehouse<\/li>\n<\/ul>\n<\/div>\n

    Catalog Federation and the Databricks Bone of Contention<\/h2>\n

    Catalog Federation is the second major lever. Google has announced bidirectional federation for Databricks Unity Catalog, Snowflake Polaris, and AWS Glue. Engines can directly write to and read from each other’s catalog – without data copies, without ETL pipelines in between. Zero-Copy-Sharing.<\/p>\n

    For DACH companies that already operate Databricks and are wondering if BigQuery is a better fit for certain workloads, this is a different conversation than it was twelve months ago. You no longer have to decide. You can start to selectively shift workloads while the data foundation remains on S3 or in Databricks.<\/p>\n

    \n

    “Migration is no longer a multi-year project. Cloud-to-cloud moves now take nine months on average. The question is not whether, but which workload first.”<\/p>\n