9 Min. Lesezeit

Google bündelt BigQuery, AlloyDB, Spanner und Apache Spark unter einem Namen und nennt das Ergebnis Agentic Data Cloud. Das klingt nach Marketing. Wird aber konkret, wenn man sich die Cross-Cloud-Lakehouse-Ankündigung genauer ansieht: BigQuery kann jetzt Iceberg-Tabellen auf Amazon S3 abfragen, ohne Egress-Gebühren, über Googles eigene Cross-Cloud-Interconnect-Leitungen. Das ist kein Feature-Announcement. Das ist ein Preisargument gegen Databricks.

Das Wichtigste in Kürze

• Cross-Cloud Lakehouse ohne Egress: BigQuery liest und schreibt Iceberg-Tabellen auf AWS S3 und Azure Data Lake Storage, ohne Egress-Gebühren via Cross-Cloud Interconnect. Kein Datenmove, kein Kopieren, kein Doppelt-Bezahlen.
• Catalog Federation bidirektional: Databricks Unity Catalog, Snowflake Polaris und AWS Glue sind jetzt föderiert. Engines lesen und schreiben direkt in den jeweils anderen Catalog. Zero-Copy-Sharing ohne ETL.
• Migration in rund 9 Monaten: Google gibt den Durchschnitt für Cloud-to-Cloud-Migrationen mit neun Monaten an – deutlich unter dem bisher kommunizierten Mehrjahres-Zeitrahmen.
• Managed Iceberg GA: BigQuery Lakehouse ist generally available mit automatischem Table Management, Multi-Table Transactions, Change Data Capture und History-Based Optimizations.

VerwandtState of FinOps 2026: Technology Value Management  /  BYOD im deutschen Enterprise 2026

Was Google unter Agentic Data Cloud versteht

Google positioniert BigQuery, AlloyDB, Spanner und Apache Spark als einheitliche Plattform gegen Databricks und Snowflake. Was das in der Praxis für DACH-Architekturen bedeutet, zeigen die Ankündigungen von Google Cloud Next 2026 im Detail.

Was ist die Google Agentic Data Cloud? Es ist die strategische Klammer um AlloyDB, BigQuery, Spanner, Bigtable und dem Managed Apache Spark Service. Ziel: Unternehmensdaten nicht mehr nur für menschliche Analysten aufbereiten, sondern als Kontext für autonome KI-Agenten verfügbar machen. Im Zentrum steht ein „Universal Context Engine“ – eine Schicht, die verhindert, dass Agenten halluzinieren, weil sie keinen Zugriff auf die richtigen Unternehmensdaten haben.

Das ist technisch konsequent gedacht. Agentic Workflows brauchen keine statischen Reports, sie brauchen Datenzugriff in Echtzeit – lesend und schreibend, über Systemgrenzen hinweg. Das war bisher das Argument für Databricks: eine offene, Spark-basierte Plattform, die im Prinzip mit allem reden kann. Google versucht jetzt, dieses Argument zu entwerten.

Konkret heißt das: Gemini-basierte Agenten in Vertex AI können direkt auf BigQuery zugreifen, ohne manuelle ETL-Pipelines. BigQuery Cortex Framework beschleunigt das mit vorgefertigten Konnektoren für SAP, Salesforce und Oracle. Das klingt nach Catalog-Lösung von der Stange – ist aber in der Breite der Integrationen und in der Tie-in-Tiefe zu GCP tatsächlich neu.

Cross-Cloud Lakehouse: der eigentliche Angriff

Der Teil, der in Databricks-Kundengesprächen relevant wird, ist nicht das Agentic-Branding. Es ist das Cross-Cloud Lakehouse. BigQuery kann jetzt Iceberg-Tabellen lesen und schreiben, die physisch auf Amazon S3 oder Azure Data Lake Storage liegen. Verbindung läuft über Cross-Cloud Interconnect – eine dedizierte private Leitung, kein öffentliches Internet, keine Egress-Gebühren.

Das ist bedeutsam, weil es das Daten-Egress-Argument kippt. Bisher war eine BigQuery-Migration oft deshalb teuer, weil Daten aus S3 oder Azure rausbewegt werden mussten. Wer heute Databricks auf AWS betreibt und BigQuery zumindest parallel testen will, muss keine großen Datenbewegungen mehr einplanen. Das Lakehouse liegt auf S3, BigQuery greift direkt drauf zu.

Verwandt: State of FinOps 2026: Warum FinOps jetzt Technology Value Management heißt und was das für DACH-Cloud-Budgets bedeutet

Catalog Federation und der Databricks-Zankapfel

Catalog Federation ist der zweite große Hebel. Google hat bidirektionale Federation für Databricks Unity Catalog, Snowflake Polaris und AWS Glue angekündigt. Engines können direkt in den jeweils anderen Catalog schreiben und lesen – ohne Datenkopien, ohne ETL-Pipelines dazwischen. Zero-Copy-Sharing.

Für DACH-Unternehmen, die heute schon Databricks betreiben und sich fragen, ob BigQuery für bestimmte Workloads besser passt, ist das ein anderes Gespräch als noch vor zwölf Monaten. Man muss sich nicht mehr entscheiden. Man kann anfangen, Workloads selektiv zu verlagern, während die Datenbasis auf S3 oder in Databricks bleibt.

„Die Migration ist kein Mehrjahresprojekt mehr. Cloud-to-Cloud-Moves gehen heute in neun Monaten im Durchschnitt. Die Frage ist nicht ob, sondern welcher Workload zuerst.“

BigQuery Lakehouse vs. Databricks für DACH-Architekturen

In DACH-Enterprise-Umgebungen läuft die Diskussion meistens entlang dreier Achsen: Governance und Datensouveränität, Total Cost of Ownership und Anbindung an bestehende SAP-Landschaften. Google hat alle drei direkt addressiert.

Wer primär Analytics, BI und Agenten-Kontext im GCP-Ökosystem baut, bekommt mit BigQuery Lakehouse heute ein ernsthaftes Argument. Wer Machine Learning Workflows auf Spark-Basis mit Data-Science-Teams betreibt und cloud-agnostisch bleiben will, hat mit Databricks weiterhin die besseren Karten.

Was das für die Entscheidung 2026 bedeutet

Der Kontext hat sich verändert. Wer 2024 noch sagte „wir bleiben auf Databricks, weil der Wechsel zu BigQuery zu viel kostet“ – das Egress-Argument gilt eingeschränkt, sobald Cross-Cloud Lakehouse in der eigenen Region verfügbar ist. Die Datenbewegung entfällt als Hauptkostenposten.

Was bleibt, sind die echten Fragen: Welche Workloads sind GCP-nah? Wo betreiben wir Machine Learning jenseits von Analytics? Wie tief ist unsere SAP-Integration? Diese Antworten entscheiden – nicht mehr der Egress-Tarif.

Für DACH-Architekten bedeutet das: Die nächste Data-Platform-Ausschreibung lohnt sich neu zu kalibrieren. Nicht weil BigQuery jetzt automatisch besser ist – sondern weil Google Cloud Next 2026 die Vergleichsbasis verschoben hat. Databricks wird darauf reagieren. Wie, wird der Rest des Jahres zeigen.

Häufige Fragen

Was ist Google Agentic Data Cloud und was unterscheidet sie von bisherigen BigQuery-Angeboten?

Agentic Data Cloud ist Googles strategische Klammer um AlloyDB, BigQuery, Spanner, Bigtable und Managed Apache Spark. Der Unterschied zu bisherigen BigQuery-Angeboten liegt im Fokus: weg von menschlicher Analyse, hin zu maschineller Datenkonsumption durch KI-Agenten. Der Universal Context Engine als neue Schicht soll Halluzinationen verhindern, indem Agenten direkten, strukturierten Zugriff auf Unternehmensdaten erhalten.

Wie funktioniert Cross-Cloud Lakehouse ohne Egress-Gebühren technisch?

BigQuery greift über Cross-Cloud Interconnect auf Iceberg-Tabellen zu, die physisch auf Amazon S3 oder Azure Data Lake Storage liegen. Cross-Cloud Interconnect ist eine dedizierte private Leitungsverbindung zwischen Google und den anderen Hyperscalern – kein öffentliches Internet, daher keine Egress-Kosten. Abfragen laufen wie native BigQuery-Queries, die Tabellen liegen auf fremder Infrastruktur.

Was bedeutet Catalog Federation für bestehende Databricks-Installationen?

Catalog Federation ermöglicht bidirektionale Verbindungen zwischen BigQuery und Databricks Unity Catalog. Engines auf beiden Seiten können direkt lesen und schreiben, ohne Datenkopien oder ETL-Pipelines. Für Unternehmen mit bestehenden Databricks-Installationen bedeutet das: BigQuery lässt sich für ausgewählte Analytics-Workloads nutzen, ohne die Databricks-Datenbasis anfassen zu müssen.

Stimmt Googles Aussage, dass Migrationen nur noch neun Monate dauern?

Google kommuniziert neun Monate als Durchschnittswert für Cloud-to-Cloud-Migrationen. Das bezieht sich auf reine Datenmigration mit Googles Migration Tools und Assessment-Tooling für Databricks-Workloads. Die Neun-Monats-Zahl klingt überzeugend, sollte aber mit eigenem Komplexitätsprofil abgeglichen werden: SAP-Integration, existierende ML-Pipelines und Governance-Anforderungen können deutlich mehr Zeit kosten.

Für welche DACH-Unternehmen ist ein Wechsel zu BigQuery Lakehouse heute sinnvoll?

Sinnvoll primär für Unternehmen, die bereits stark im GCP-Ökosystem arbeiten und Analytics-Workloads von Spark-basierten ML-Workflows trennen können. Starke SAP-Landschaften profitieren von Cortex-Konnektoren. Wer hingegen Data-Science-Teams mit tiefer Spark-Expertise hat und Databricks MLflow-Workflows betreibt, hat keinen zwingenden Grund zu wechseln – Federation ermöglicht heute Koexistenz statt entweder/oder.

Quelle Titelbild: KI-generiert via nano

Foto: Pexels (CC0)