Der Kernunterschied zu einer herkömmlichen Datenbank: BigQuery müssen Sie nicht betreiben. Es gibt keine Server, die Sie dimensionieren, keine Cluster, die Sie starten, kein Patch-Management und kein klassisches Tuning. Sie laden Ihre Daten in ein sogenanntes „Dataset“, schreiben SQL – und BigQuery kümmert sich um Verteilung, Parallelisierung und Optimierung im Hintergrund. Genau dieser „serverlose“ Ansatz unterscheidet BigQuery von Systemen, bei denen Sie zumindest die Größe eines Rechen-Clusters selbst festlegen müssen.
Drei Eigenschaften definieren BigQuery:
In Gesprächen werden die Begriffe oft durcheinandergeworfen. Eine Datenbank im klassischen Sinn (etwa PostgreSQL oder Microsoft SQL Server) ist für das schnelle Schreiben und Lesen einzelner Datensätze in operativen Anwendungen optimiert. Ein Data Warehouse ist dagegen für analytische Abfragen über große Datenmengen ausgelegt – also für Fragen wie „Wie hat sich der Deckungsbeitrag pro Region über die letzten drei Jahre entwickelt?“. BigQuery ist im Kern ein solches analytisches Data Warehouse.
Der Zusatz serverlos beschreibt dabei nicht, dass keine Server im Spiel wären – natürlich läuft BigQuery auf der gewaltigen Infrastruktur von Google. Gemeint ist vielmehr, dass Sie diese Infrastruktur nicht sehen, verwalten oder dimensionieren müssen. Für die Praxis ist die begriffliche Unterscheidung weniger wichtig als das Verständnis: BigQuery ist der zentrale Ort, an dem Ihre Analysedaten leben – und von dem aus Berichte, Dashboards und Datenprodukte gespeist werden.
BigQuery hat seine Wurzeln in einer internen Google-Technologie zur Auswertung riesiger Datenmengen und wurde vor über einem Jahrzehnt als kommerzieller Dienst verfügbar gemacht. Dieser Ursprung erklärt eine zentrale Stärke: BigQuery ist von Grund auf für die massiv parallele Verarbeitung enorm großer Datenbestände gebaut. Wo klassische Systeme bei Milliarden von Zeilen ins Schwitzen geraten, verteilt BigQuery die Arbeit im Hintergrund auf sehr viele Rechenknoten. Für Mittelständler, deren Datenmengen längst nicht diese Dimensionen erreichen, bedeutet das schlicht: Die Plattform wird selten der begrenzende Faktor sein.
Der zentrale Begriff für BigQuerys Rechenleistung ist der Slot. Ein Slot ist eine abstrakte Einheit von Rechenkapazität, die BigQuery einer Abfrage zuweist. Eine komplexe Abfrage über viele Daten nutzt viele Slots parallel, eine kleine Abfrage entsprechend wenige. Der entscheidende Unterschied zu manch anderer Plattform: Sie starten und dimensionieren keine Rechen-Cluster selbst. BigQuery verteilt die verfügbaren Slots automatisch auf die anstehenden Abfragen. Das nimmt Ihnen eine ganze Klasse von Betriebsentscheidungen ab – und ist zugleich der Grund, warum die Kostensteuerung anders funktioniert als bei cluster-basierten Systemen.
Für die Praxis heißt das: Der wichtigste Hebel ist nicht die Wahl einer Cluster-Größe, sondern wie viele Daten eine Abfrage verarbeitet – und, je nach Preismodell, wie viel Slot-Kapazität dauerhaft bereitsteht. Wer effizient modelliert und Abfragen so gestaltet, dass sie nur die wirklich benötigten Daten anfassen, hat den größten Einfluss auf Leistung und Kosten.
BigQuery bietet grundsätzlich zwei Wege, Rechenleistung zu beziehen. Im On-Demand-Modell zahlen Sie pro abgefragtem Datenvolumen – vereinfacht: Je mehr Daten eine Abfrage scannt, desto höher die Kosten, unabhängig davon, wie lange sie läuft. Dieses Modell ist einfach, erfordert keine Vorabplanung und eignet sich gut für schwankende, schwer vorhersehbare Lasten und für den Einstieg.
Bei den kapazitätsbasierten Editionen reservieren oder buchen Sie stattdessen eine bestimmte Menge an Slot-Kapazität und zahlen für diese – unabhängig vom abgefragten Datenvolumen. Google bietet hier gestufte Editionen mit unterschiedlichem Funktionsumfang an sowie Optionen für automatisch mitwachsende Kapazität. Dieses Modell lohnt sich in der Regel, sobald die Nutzung ein gewisses, stabiles Niveau erreicht und planbar wird. Welche Variante günstiger ist, hängt vom konkreten Nutzungsmuster ab – das ist eine Rechnung, die man für den Einzelfall aufstellen muss.
BigQuery ist nicht als isoliertes Produkt gedacht, sondern als analytisches Herzstück der Google Cloud. Es ist eng mit den umliegenden Diensten verzahnt – von der Datenintegration über die Rechteverwaltung bis zu KI- und BI-Werkzeugen. Diese enge Integration ist eine der größten Stärken, hat aber eine wichtige Kehrseite: Anders als cloud-neutrale Wettbewerber ist BigQuery an die Google Cloud gebunden. Wer BigQuery einführt, entscheidet sich zumindest für diesen Teil der Datenlandschaft für Google als Plattform. Diese strategische Bindung sollte bewusst getroffen und nicht nebenbei entschieden werden.
In BigQuery werden Daten in Datasets organisiert – logischen Behältern, die Tabellen und Ansichten (Views) bündeln. Datasets sind zugleich die Ebene, auf der viele Zugriffsrechte und Regionen-Einstellungen greifen: Ein Dataset ist an eine bestimmte Region gebunden, was für die Datenhoheit wichtig ist (mehr dazu in Kapitel 09). Diese klare, überschaubare Struktur – Projekt, Dataset, Tabelle – macht es vergleichsweise leicht, eine saubere Ordnung anzulegen, in der sich auch nach Jahren noch alle zurechtfinden. Aus unserer Erfahrung ist eine durchdachte Dataset- und Namenskonvention einer der unterschätzten Erfolgsfaktoren jeder BigQuery-Einführung.
Zwei Funktionen wirken auf den ersten Blick technisch, entfalten in der Praxis aber enormen Nutzen – gerade weil im On-Demand-Modell nach abgefragtem Datenvolumen abgerechnet wird. Eine partitionierte Tabelle, etwa nach Kalendertag, erlaubt es BigQuery, bei einer Abfrage für einen bestimmten Zeitraum nur die betroffenen Tage zu lesen statt der gesamten Historie. Clustering sortiert die Daten innerhalb der Partitionen zusätzlich so, dass gezielte Filter noch weniger Daten anfassen müssen. Beides zusammen senkt sowohl die Antwortzeiten als auch – im On-Demand-Modell direkt spürbar – die Kosten. Wer diese Werkzeuge ignoriert, bezahlt bei jeder Abfrage unnötig viel; wer sie beherrscht, macht BigQuery schnell und wirtschaftlich zugleich. Das ist einer der Punkte, an denen sich gute BigQuery-Implementierungen von schlechten unterscheiden.
Ein häufig übersehener Baustein ist die BI Engine. Sie ist ein integrierter, im Arbeitsspeicher arbeitender Beschleuniger, der häufig abgefragte Daten vorhält und so die Antwortzeiten interaktiver Dashboards drastisch verkürzt. Für den typischen Anwendungsfall – ein Management-Dashboard, das viele Nutzer gleichzeitig und wiederholt öffnen – ist das entscheidend: Ohne solche Beschleunigung würde jede Interaktion eine neue Abfrage auslösen. Mit der BI Engine bleiben die Berichte flüssig, ohne dass Sie die Daten in ein separates System kopieren müssten. Das ist ein wichtiger Grund, warum BigQuery nicht nur als Batch-Analyse-Werkzeug, sondern als Fundament für lebendige BI taugt.
Die Grundidee folgt einem klaren Prinzip: Bring die Analyse zu den Daten, nicht die Daten zur Analyse. Statt große Datenmengen aus BigQuery herauszukopieren, sie in einer separaten Umgebung zu verarbeiten und die Ergebnisse zurückzuspielen, lässt BigQuery viele Berechnungen direkt dort laufen, wo die Daten liegen. Das reduziert Datenbewegungen, vereinfacht die Governance und hält sensible Daten innerhalb der kontrollierten Plattform – ein Aspekt, der gerade unter Datenschutz-Gesichtspunkten relevant ist.
BigQuery ML erlaubt es, Machine-Learning-Modelle direkt in BigQuery zu erstellen, zu trainieren und anzuwenden – mit vertrauten SQL-Befehlen, ohne die Plattform zu verlassen und ohne dass Datenanalysten zu Programmierern werden müssten. Damit lassen sich typische Aufgaben abbilden: Prognosen (etwa von Absätzen oder Nachfrage), Klassifikationen (etwa die Abschätzung von Abwanderungsrisiken) oder Segmentierungen von Kunden. Für Unternehmen heißt das: Das bestehende SQL-Team kann erste ML-Anwendungen umsetzen, statt zunächst eine eigene Data-Science-Abteilung aufbauen zu müssen.
Realistisch eingeordnet: BigQuery ML ist stark für Modelle auf strukturierten Unternehmensdaten und für den pragmatischen Einstieg ins maschinelle Lernen. Für hochspezialisierte Deep-Learning-Forschung mit großen Rechenanforderungen ist die enger darauf ausgelegte Google-Cloud-Plattform für KI (Vertex AI) oder eine spezialisierte ML-Plattform die naheliegendere Wahl – wobei BigQuery und Vertex AI eng zusammenarbeiten. Im typischen Mittelstands-Szenario deckt BigQuery ML den Bedarf jedoch gut ab.
Google integriert seine KI-Familie Gemini zunehmend in BigQuery. In der Praxis bedeutet das assistierende Funktionen: Unterstützung beim Schreiben und Erklären von SQL, das Erzeugen von Abfragen aus natürlichsprachlichen Beschreibungen oder Vorschläge zur Aufbereitung von Daten. Das Data Canvas ist eine visuelle, dialogorientierte Oberfläche, in der sich Datenanalysen eher durch Fragen und Bausteine als durch reinen Code zusammenstellen lassen. Der Anspruch dahinter: Auch fachlich versierte Anwender ohne tiefes SQL-Wissen sollen mit den Daten arbeiten können.
Aus Beratungssicht ist das eine vielversprechende, aber noch junge und sich schnell entwickelnde Funktionsfamilie. Wir empfehlen, solche KI-Assistenten zunächst als Beschleuniger für erfahrene Anwender zu betrachten – als Werkzeug, das Routinearbeit abnimmt und Vorschläge liefert –, statt sich blind auf generierte Abfragen zu verlassen. Jede von einer KI erzeugte Auswertung sollte fachlich geprüft werden, bevor Geschäftsentscheidungen darauf aufbauen.
Ein weiterer Baustein ist die Vektorsuche. Sie erlaubt es, Daten – etwa Texte, Produktbeschreibungen oder Dokumente – nicht nur nach exakten Übereinstimmungen, sondern nach inhaltlicher Ähnlichkeit zu durchsuchen. Das ist die Grundlage moderner KI-Anwendungen wie semantischer Suche, Empfehlungssystemen oder der Anbindung von Sprachmodellen an eigene Unternehmensdaten. Dass diese Funktion direkt in BigQuery verfügbar ist, erspart den Aufbau einer separaten spezialisierten Datenbank für solche Anwendungsfälle – ein Vorteil, wenn semantische Suche zu einem bestehenden Data Warehouse hinzukommen soll, statt eine ganz neue Infrastruktur zu erfordern.
Der typische Aufbau in unseren Projekten sieht so aus: BigQuery ist die „Single Source of Truth“ – der eine, verlässliche Ort, an dem alle Analysedaten zusammenlaufen, sauber modelliert und mit Zugriffsrechten versehen. Darum herum liegen die Werkzeuge, die Daten einspeisen, transformieren und darstellen. Weil die Rechenleistung in BigQuery liegt, bleiben die BI-Tools schlank: Sie schicken Abfragen an BigQuery und stellen nur die Ergebnisse dar. Das hält auch große Datenmengen handhabbar.
Innerhalb der Google-Welt sind Looker und Looker Studio die naheliegenden BI-Werkzeuge. Looker ist die unternehmensweite BI-Plattform mit einer zentralen Modellierungs-Schicht, in der Geschäftskennzahlen einmal definiert und dann konsistent überall genutzt werden. Looker Studio ist das leichtgewichtigere, kostenfrei nutzbare Werkzeug für Dashboards und Berichte, das sich besonders für schnelle Auswertungen und die Anbindung von Google-Datenquellen eignet. Beide harmonieren naturgemäß sehr gut mit BigQuery.
Für den deutschen Mittelstand ist zugleich Microsoft Power BI das mit Abstand verbreitetste BI-Werkzeug – und auch die Kombination mit BigQuery ist ausgereift. Power BI verbindet sich über einen nativen Connector und bietet die üblichen Modi: den Import-Modus, bei dem Daten ins Power-BI-Modell geladen werden (sehr schnell für Nutzer, aber mit regelmäßigen Aktualisierungen), und DirectQuery, bei dem die Rechenlast in BigQuery bleibt und jede Interaktion als Abfrage durchgereicht wird. Die Wahl zwischen beiden Modi hat unmittelbare Auswirkungen auf Aktualität, Performance und – im On-Demand-Modell – auf die Kosten. In der Praxis bewährt sich häufig ein gemischter Ansatz.
Damit Daten überhaupt in BigQuery landen, braucht es Wege des Datentransfers. Google bietet dafür eigene Dienste – etwa geplante Übernahmen aus Google-eigenen Quellen wie Google Ads oder Analytics, Streaming-Aufnahme für kontinuierlich eintreffende Daten sowie Orchestrierungs- und ETL-Werkzeuge innerhalb der Cloud. Daneben verbinden sich die gängigen Integrationswerkzeuge des Marktes – etwa Fivetran, Airbyte oder Talend – problemlos mit BigQuery und binden Standardquellen wie ERP- und CRM-Systeme, Datenbanken und Online-Dienste an.
Ein häufig übersehener, aber entscheidender Baustein ist die Transformations-Schicht zwischen Rohdaten und BI. Werkzeuge wie dbt modellieren die Daten direkt in BigQuery zu sauberen, dokumentierten und getesteten Analysetabellen, bevor sie ins BI-Tool gelangen. Dieser Schritt entscheidet maßgeblich über die Qualität und Vertrauenswürdigkeit der späteren Berichte – und ist aus unserer Sicht kein Nice-to-have, sondern Pflicht für eine belastbare Analytics-Landschaft.
Eine Antwort auf die berechtigte Sorge vor zu enger Cloud-Bindung ist BigQuery Omni. Damit lassen sich Daten, die in anderen Clouds liegen, mit der vertrauten BigQuery-Oberfläche und -Abfragesprache analysieren, ohne sie zuvor vollständig zu Google zu verschieben. Für Unternehmen mit einer bewussten Multi-Cloud-Strategie kann das die Bindung an eine einzige Cloud abmildern. In der Praxis bleibt BigQuery jedoch am stärksten in seiner Heimat, der Google Cloud – Omni ist eine sinnvolle Ergänzung für bestimmte Szenarien, kein vollständiger Ersatz für die native Nutzung.
Ein klassisches Data Warehouse arbeitet mit strukturierten, aufbereiteten Daten und ist auf zuverlässige, schnelle SQL-Analysen optimiert. Ein Data Lake sammelt dagegen rohe Daten aller Art kostengünstig, ist aber ohne zusätzliche Werkzeuge schwer zu beherrschen. Das Lakehouse verspricht, beide Welten zu vereinen. BigQuery kommt klar aus der Data-Warehouse-Welt und ist dort am stärksten – hat sich aber, wie die Wettbewerber, in benachbarte Bereiche wie ML und die Verarbeitung offener Datenformate erweitert. Die Grenzen zwischen den Plattformen verschwimmen zunehmend.
Aus unserer Beratungspraxis kristallisieren sich klare Muster heraus. BigQuery ist meist die richtige Wahl, wenn ein Unternehmen ohnehin in der Google-Welt verankert ist – etwa mit Google Analytics, Google Ads oder Google Workspace –, wenn ein wirklich serverloser Betrieb ohne jegliche Cluster-Verwaltung gewünscht ist und wenn der Schwerpunkt auf schneller SQL-Analytik und BI liegt. Die niedrige Einstiegshürde und das mühelose Skalieren machen BigQuery gerade für Mittelständler attraktiv, die klein starten und wachsen wollen.
Snowflake ist oft vorzuziehen, wenn eine bewusst cloud-neutrale Plattform gewünscht ist, die sich nicht an einen einzelnen Hyperscaler bindet. Databricks spielt seine Stärken aus, wenn anspruchsvolles Data Engineering und fortgeschrittenes Machine Learning im Zentrum stehen und das Team über Code-Know-how verfügt. Amazon Redshift ist naheliegend, wenn ein Unternehmen tief in der AWS-Welt zu Hause ist. Wichtig: Es gibt selten ein objektiv „bestes“ System – die richtige Wahl hängt von Datenstrategie, vorhandenen Kompetenzen und der bestehenden Cloud-Landschaft ab.
Der häufigste Fehler ist, BigQuery als Selbstzweck einzuführen – „weil wir jetzt ein Data Warehouse brauchen“. Erfolgreiche Projekte starten umgekehrt: mit einem konkreten, schmerzhaften Geschäftsproblem. Typische Einstiegs-Use-Cases im Mittelstand sind etwa ein abteilungsübergreifendes Vertriebs- und Deckungsbeitrags-Reporting, das heute mühsam aus mehreren Systemen in Excel zusammengetragen wird; die Zusammenführung von Marketing-Daten aus Google Ads, Analytics und weiteren Kanälen zu einer belastbaren Marketing-Auswertung; oder eine 360-Grad-Sicht auf den Kunden aus ERP-, CRM- und Webshop-Daten.
Der Vorteil dieses Vorgehens: Ein klar umrissener erster Anwendungsfall liefert schnell sichtbaren Wert, schafft Akzeptanz im Unternehmen und hält den Aufwand überschaubar. Das serverlose, verbrauchsbasierte Modell von BigQuery unterstützt das ideal – Sie können klein beginnen und wachsen, ohne anfangs in Infrastruktur investieren zu müssen.
Steht der erste Use-Case, geht es an die Daten. In den meisten Fällen müssen Daten aus den Quellsystemen regelmäßig nach BigQuery geladen werden. Hier kommen die in Kapitel 05 beschriebenen Wege ins Spiel – Googles eigene Transferdienste ebenso wie spezialisierte Integrationswerkzeuge des Marktes. Direkt in BigQuery werden die Rohdaten anschließend in saubere, dokumentierte Analysetabellen modelliert, sinnvoll partitioniert und geclustert – ein Schritt, der über spätere Performance, Kosten und Datenqualität entscheidet.
Wer von einem bestehenden, klassischen Data Warehouse migriert, sollte den Aufwand nicht unterschätzen: SQL-Dialekte unterscheiden sich, gewachsene Logik muss überprüft und oft neu strukturiert werden, und nicht jede alte Berechnung verdient es, eins zu eins übernommen zu werden. Eine Migration ist immer auch eine Chance, Altlasten zu bereinigen. Wir empfehlen ein schrittweises Vorgehen pro Datenbereich statt eines riskanten Big-Bang-Umzugs.
Ein zentraler Erfolgsfaktor ist Governance – und zwar von Beginn an. Dazu gehört ein durchdachtes rollenbasiertes Rechtekonzept über die zentrale Google-Cloud-Rechteverwaltung (IAM), das festlegt, wer welche Datasets sehen und welche Abfragen ausführen darf. Dazu gehören klare Namens- und Strukturkonventionen für Projekte, Datasets und Tabellen, damit die Plattform nicht im Wildwuchs endet. Und dazu gehört die Kostensteuerung, auf die Kapitel 09 näher eingeht. Gerade im Mittelstand, wo oft wenige Personen viele Rollen tragen, ist diese Struktur entscheidend, damit die Plattform auch nach dem ersten Projekt wartbar und sicher bleibt. BigQuery macht den technischen Betrieb einfach – die organisatorische Disziplin müssen Sie selbst mitbringen.
Besonders naheliegend ist BigQuery für Unternehmen mit einem starken digitalen Vertriebs- oder Marketingkanal. Wer Google Analytics, Google Ads und weitere Kanäle nutzt, kann diese Daten mit vergleichsweise geringem Aufwand nach BigQuery bringen und dort mit den kaufmännischen Daten aus ERP und CRM verknüpfen. So entsteht eine belastbare Sicht darauf, welche Marketing-Ausgaben tatsächlich zu profitablen Kunden führen – eine Frage, die viele Unternehmen mit isolierten Tool-Berichten nicht sauber beantworten können.
Weitere typische Felder sind ein unternehmensweites Management-Reporting, das Kennzahlen aus verschiedenen Abteilungen zusammenführt; die Auswertung von Produktions- und Maschinendaten gemeinsam mit kaufmännischen Kennzahlen; oder die Analyse großer Mengen an Transaktions- und Ereignisdaten, etwa aus einem Online-Shop oder einer digitalen Anwendung. In all diesen Fällen spielt BigQuery seine Stärke aus, sehr große Datenmengen ohne Infrastruktur-Aufwand analysierbar zu machen.
Ein erster, klar umrissener BigQuery-Use-Case – von der Anbindung der Quellsysteme über die Datenmodellierung bis zum produktiven Dashboard – ist in vielen Mittelstands-Projekten in wenigen Wochen bis wenigen Monaten umsetzbar. Der Aufbau einer breiten, unternehmensweiten Datenplattform mit vielen Quellen, sauberer Governance und mehreren Fachbereichen ist dagegen ein fortlaufendes Programm über mehrere Monate. Wer mit einem fokussierten Pilotprojekt startet und daraus lernt, baut die Plattform tragfähig aus – statt sich an einem überdimensionierten Erstwurf zu verheben. Genau an dieser Schnittstelle zwischen Technik, Daten und Organisation setzt unsere Beratungsarbeit an.
BigQuery rechnet im Kern über zwei Komponenten ab: Speicher und Rechenleistung. Der Speicher wird pro gespeichertem Datenvolumen und Monat berechnet und ist in der Regel der kleinere, gut planbare Teil der Rechnung. Die Rechenleistung ist der variable und interessante Teil: Im On-Demand-Modell zahlen Sie nach dem von einer Abfrage verarbeiteten Datenvolumen, bei den kapazitätsbasierten Editionen nach reservierter oder genutzter Slot-Kapazität. Konkrete Eurobeträge nennen wir bewusst nicht – die Preise unterscheiden sich je nach Edition, Region und Vertrag und ändern sich über die Zeit. Verlässlich ist nur das Prinzip: Sie zahlen für verarbeitete Daten bzw. bereitgestellte Kapazität und für gespeicherte Daten, und beides lässt sich aktiv steuern.
Die häufigste böse Überraschung entsteht nicht durch BigQuery selbst, sondern durch unbedachte Nutzung – besonders im On-Demand-Modell. Typische Ursachen sind: Abfragen, die aus Bequemlichkeit ganze Tabellen scannen, statt nur die benötigten Spalten und Zeiträume; fehlende Partitionierung und fehlendes Clustering, sodass jede Abfrage mehr Daten liest als nötig; sowie ineffizient gebaute Dashboards, die bei jeder Interaktion große Datenmengen anfassen. Die gute Nachricht: Genau hier liegen auch die wirksamsten Hebel zur Kostenkontrolle.
Aus unserer Sicht ist die Kostensteuerung kein einmaliges Setup, sondern eine laufende Disziplin – vergleichbar mit dem bewussten Umgang mit Cloud-Ausgaben generell (oft als „FinOps“ bezeichnet). Unternehmen, die von Anfang an klare Verantwortlichkeiten, Budgets und Monitoring etablieren, erleben BigQuery als planbar und wirtschaftlich. Der Unterschied liegt nicht in der Technik, sondern in der Governance.
BigQuery ist ein Dienst von Google, einem US-amerikanischen Konzern, der auf Googles eigener globaler Infrastruktur läuft. Für deutsche und europäische Unternehmen wirft das berechtigte Fragen zu Datenschutz und Datenhoheit auf. Google bietet hier wichtige Stellschrauben – die endgültige Bewertung bleibt jedoch eine Frage des Einzelfalls.
Der wichtigste Hebel für die Datenhoheit ist die Wahl der Region. Google Cloud ist in zahlreichen Regionen weltweit verfügbar – darunter mehrere in der Europäischen Union, etwa in Frankfurt oder Belgien. In BigQuery wird die Region auf Ebene des Datasets festgelegt: Wer eine EU-Region wählt, sorgt dafür, dass die betreffenden Daten physisch in europäischen Rechenzentren liegen und dort verarbeitet werden. Das ist eine notwendige Grundlage für einen DSGVO-konformen Betrieb und reduziert das Risiko, dass Daten unbeabsichtigt in Drittländer abfließen. Google stellt zudem die üblichen vertraglichen Instrumente bereit – insbesondere einen Auftragsverarbeitungsvertrag und Standardvertragsklauseln – und verfügt über etablierte Zertifizierungen und Sicherheitsstandards.
Bestehen bleibt – auch bei Speicherung in einer EU-Region – ein grundsätzliches Thema: Google ist ein US-Mutterkonzern und unterliegt damit potenziell US-amerikanischem Recht, ein Punkt, der seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird. Die EU-Region adressiert den Aspekt der Datenlokalisierung, beseitigt aber nicht jedes theoretische Zugriffsrisiko, das aus der US-Konzernzugehörigkeit folgen könnte. In der Praxis ist dieses Restrisiko für viele Mittelständler mit überschaubar sensiblen Analysedaten vertretbar – insbesondere mit EU-Region, sauberem Auftragsverarbeitungsvertrag, Verschlüsselung und Datenminimierung. Für besonders schützenswerte Datenkategorien oder hohe Souveränitätsanforderungen kann die Bewertung anders ausfallen; dann sind zusätzliche Schutzmaßnahmen, eine Datenschutz-Folgenabschätzung oder europäische bzw. souveräne Alternativen zu prüfen.
