Brauchst du eine Graphdatenbank? Was die GA von BigQuery Graph wirklich ändert

Gestern hat Google BigQuery Graph in die allgemeine Verfügbarkeit überführt, und die Ankündigung lehnt sich weit aus dem Fenster mit dem Wort agentisch: Knowledge Graphs als Fundament für KI-Agenten, auditierbares Agentengedächtnis, Chat in natürlicher Sprache über Ihre Beziehungen. Es ist ein guter Launch, und er wird eine Welle von Beiträgen auslösen, die erklären, dass Graphen die Zukunft der Unternehmensdaten sind.

Dies ist keiner davon. Bevor Sie irgendetwas als Knoten und Kanten modellieren, lohnt sich eine deutlich unspektakulärere Frage: Braucht Ihr Problem wirklich eine Graph-Engine, oder braucht es drei Joins und einen Index? Die meisten Teams, die zur Graphdatenbank greifen, brauchen keine — und die, die eine brauchen, merken es immer gleich: an einer Abfrage, die sich nicht schreiben lässt, weil die Tiefe unbekannt ist. Dieser Text zeigt, wie Sie beide Fälle unterscheiden, was die GA tatsächlich geändert hat, und welche eine Zeile in der Preisdokumentation darüber entscheidet, ob Sie überhaupt loslegen können.

Was eine Graph-Engine wirklich bringt

Der übliche Pitch lautet, Graphdatenbanken seien für „vernetzte Daten”. Dieser Pitch ist nahezu bedeutungslos, denn eine relationale Datenbank bildet Verbindungen einwandfrei ab — genau dafür gibt es Fremdschlüssel.

Der echte Unterschied ist enger und viel nützlicher: Eine Graph-Engine erlaubt Traversierung bis zu einer Tiefe, die Sie beim Schreiben der Abfrage nicht kennen.

Ein konkretes Beispiel. Ein Konto ist als Betrugsverdacht markiert. Welche Konten haben von ihm Geld erhalten, innerhalb von ein bis drei Überweisungen?

In SQL ist die Drei eine strukturelle Tatsache, die im Statement stehen muss. Jeder Sprung ist ein weiterer Self-Join:

-- Exakt drei Sprünge. Nicht einer, nicht zwei, nicht vier.
SELECT DISTINCT a3.id AS reached
FROM transfers t1
JOIN transfers t2 ON t2.from_id = t1.to_id
JOIN transfers t3 ON t3.from_id = t2.to_id
JOIN accounts  a3 ON a3.id = t3.to_id
WHERE t1.from_id = 7;

Sie wollen ein bis drei Sprünge? Vereinigen Sie drei Varianten dieser Abfrage. Bis zu sechs? Schreiben Sie sechs. „So weit, bis die Spur endet”? Jetzt brauchen Sie einen rekursiven CTE, und die Lesbarkeit bricht zusammen.

In GQL ist die Tiefe ein Quantor, und die Abfrage ändert kaum ihre Form:

GRAPH graph_db.FinGraph
MATCH (src:Account {id: 7})-[e:Transfers]->{1, 3}(dst:Account)
WHERE src != dst
RETURN ARRAY_LENGTH(e) AS hops, dst.id AS dst_account_id

Das {1, 3} ist das gesamte Argument für Graphdatenbanken in einem einzigen Token. Ändern Sie es zu {1, 6} und Sie haben nichts umgebaut. Die Variable e bindet an ein Array der tatsächlich durchlaufenen Kanten, sodass ARRAY_LENGTH(e) angibt, wie weit entfernt jedes Ergebnis gefunden wurde.

Damit der ehrliche Test. Sehen Sie sich an, welche Fragen Ihr Geschäft tatsächlich stellt. Ist die Anzahl der Sprünge immer bekannt und klein — Kunde zu Bestellung zu Position —, beschreiben Sie einen Join, und eine Graph-Engine fügt eine Modellierungsschicht hinzu, aber keine Antwort. Ist die Anzahl der Sprünge selbst unbekannt, erst zu entdecken oder unbegrenzt — wie hängt diese Identität mit jener zusammen, was hängt von dieser Komponente ab, wo ist diese Zahlung am Ende gelandet —, dann ist das eine Traversierung, und SQL wird sich weiter gegen Sie wehren.

Die Falle im Standard-Pfadmodus

Ein Detail verdient Aufmerksamkeit, bevor Sie einem Traversierungsergebnis trauen, denn es ist ein echter Fallstrick und standardmäßig aktiv.

GQL kennt Pfadmodi. Der Standard ist WALK, und WALK interessiert es nicht, ob ein Pfad denselben Knoten oder dieselbe Kante zweimal berührt. Ein Muster über drei Sprünge liefert unter WALK bereitwillig einen Pfad zurück, bei dem die erste und die dritte Kante buchstäblich dieselbe Überweisung sind, hin und her gesprungen.

Zwei Modi beheben das:

• ACYCLIC filtert Pfade mit wiederholten Knoten heraus
• TRAIL filtert Pfade mit wiederholten Kanten heraus

Das Beispiel aus der Dokumentation ist aufschlussreich: Im Beispielgraphen FinGraph liefert die Frage nach sechs aufeinanderfolgenden Überweisungen mit TRAIL null Pfade, weil es schlicht keine Sechs-Sprung-Route durch diesen Graphen gibt, ohne eine Kante wiederzuverwenden. Unter WALK hätte dieselbe Form Ergebnisse geliefert — allesamt Artefakte des Im-Kreis-Laufens.

Dazu kommen die Pfadsuch-Präfixe, die man kennen sollte: ALL (Standard), ANY, ANY SHORTEST und ANY CHEAPEST, wobei letzteres einen COST-Ausdruck je Kante aufsummiert:

GRAPH graph_db.FinGraph
MATCH ANY CHEAPEST (a:Account)-[t:Transfers COST t.amount]->{1,3}(b:Account)
LET total_cost = sum(t.amount)
RETURN a.id AS a_id, b.id AS b_id, total_cost

Ein Pfad kann einen Modus oder ein Suchpräfix tragen, aber nicht beides auf oberster Ebene. Liefert Ihre erste Graphabfrage verdächtig viele Ergebnisse, prüfen Sie zuerst den Pfadmodus.

Was die GA tatsächlich geändert hat

Nun zum Launch selbst, getrennt nach dem, was ausgeliefert ist, und dem, was angekündigt wurde.

Graphen über Tabellen, die Sie schon haben. Das ist die substanzielle architektonische Aussage, und sie hält stand. Sie definieren Knoten- und Kantentabellen über vorhandene Tabellen oder Views mit CREATE PROPERTY GRAPH — keine Replikation, keine Pipeline-Änderung. Die Dokumentation von Google stellt klar, dass der Speicher der zugrunde liegenden Tabellen nur einmal berechnet wird, unabhängig von der Zahl der darauf gebauten Graphmodelle. Damit fällt der historische Grund weg, an dem Graphprojekte gescheitert sind: eine zweite Datenbank aufzusetzen und einen ETL-Job zu bauen, der sie füttert.

Ein Graph über Cloud-Grenzen hinweg. Der GA-Beitrag führt ein, was Google borderless graph Lakehouse nennt — ein einzelner Property Graph, dessen Knoten- und Kantentabellen auf native BigQuery-Tabellen und auf Iceberg-Tabellen über Databricks Unity Catalog, AWS Glue oder Snowflake zeigen können, traversiert an Ort und Stelle. Wenn das so funktioniert wie beschrieben, ist es das Interessanteste an der Ankündigung, denn der übliche Todesfall eines Unternehmens-Knowledge-Graphen ist, dass die Hälfte der Entitäten dort liegt, wo Sie nicht kopieren dürfen.

Standards statt Dialekt. GQL ist ISO/IEC 39075:2024, veröffentlicht im April 2024 — eine 610-seitige Spezifikation von ISO/IEC JTC 1/SC 32. BigQuery Graph implementiert eine Schnittstelle, die sowohl dazu als auch zu ISO SQL/PGQ kompatibel ist. Ob Sie je wechseln oder nicht: Die Mustersyntax zu lernen ist kein anbieterspezifisches Wissen.

Performance-Aussagen als Aussagen behandeln. Der Beitrag nennt GQL doppelt so schnell wie zur Preview und ungerichtete Traversierung hundertmal schneller, „gegen öffentliche Benchmarks”. Kein Benchmark wird benannt, keine Methodik genannt. Das ist eine Herstellerzahl über das eigene Produkt gegenüber der eigenen Vorversion — plausibel, nicht überprüfbar, und nichts, was in ein Architekturdokument gehört. Nehmen Sie die Richtung ernst und den Faktor als Marketing, bis ihn jemand Unabhängiges reproduziert.

Agentische Funktionen, Kleingedrucktes lesen. Chat mit dem Graphen in natürlicher Sprache, ein Agenten-Skill für Claude Code, Codex und VS Code über das Data Agent Kit, sowie ein Context Graph in BigQuery Agent Analytics, der die Entscheidungen eines Agenten als traversierbare Spur speichert. Letzteres ist wirklich clever — „warum hat der Agent das getan?” wird zu einer Graphabfrage. Aber der Beitrag sagt unumwunden, dass ein Teil des Beschriebenen heute allgemein verfügbar ist und ein Teil in Preview oder erst in den kommenden Wochen ausgerollt wird; die schreibende Hälfte des Agenten-Skills ist ausdrücklich „bald verfügbar”. Planen Sie nicht mit dem, was noch nicht da ist.

Die Zeile in der Preisdokumentation

Jetzt der Teil, der darüber entscheidet, ob Ihnen das alles offensteht — und der in der Ankündigung nicht vorkommt.

Aus der Dokumentation zu BigQuery Graph:

Um GQL-Abfragen auszuführen, benötigen Sie eine Reservierung, die die Edition Enterprise oder Enterprise Plus verwendet. Bei On-Demand-Preisen können Sie die Funktion GRAPH_EXPAND aufrufen, um SQL-Abfragen auf Ihrem Graphen auszuführen.

Lesen Sie das zweimal. GQL — der ganze Grund, eine Graph-Engine einzusetzen — hängt an einer Edition. Bei On-Demand-Abrechnung, wo ein großer Teil der BigQuery-Lasten startet und viele bleiben, bekommen Sie eine Funktion für SQL, nicht die Sprache für Mustervergleiche. Die Dokumentation warnt zusätzlich, dass die Funktion bei Reservierungen bestimmter Editionen womöglich gar nicht verfügbar ist.

Nichts davon macht das Produkt schlechter. Es macht die Bewertung anders: Das ist eine Funktion für Organisationen, die ohnehin kapazitätsbasiert abrechnen, und nichts, was Sie freitags nebenbei im Sandbox-Projekt ausprobieren. Klären Sie, auf welcher Seite dieser Linie Sie stehen, bevor Sie einen Sprint in die Modellierung von Knoten und Kanten stecken. Dieselbe Disziplin gilt für jede BigQuery-Verpflichtung, was ich ausführlicher in BigQuery vs. Snowflake durchgegangen bin.

Analytik oder Betrieb — zwei Produkte, eine Sprache

Wenn Sie sich für einen Graphen entscheiden, folgt eine zweite Weggabelung, und hier ist Google ungewöhnlich deutlich.

BigQuery Graph und Spanner Graph teilen Graphschema und Abfragesprache. Sie teilen nicht die Last.

Die entscheidende Frage ist nicht die Größe, sondern ob jemand wartet. Eine Kartenzahlung gegen einen Graphen bekannter betrügerischer Geräte zu prüfen, muss in Millisekunden geschehen, während die Transaktion offen ist — das ist Spanner Graph. Jedes Konto zu finden, das über wenige Grade mit einem bestätigten Betrüger verbunden ist, quer durch die gesamte Historie, ist ein Scan, der Minuten dauern darf — das ist BigQuery Graph.

Weil Schema und Sprache geteilt sind, entscheiden Sie sich nicht für immer. Google dokumentiert den Wechsel in beide Richtungen: Forward-ETL von Spanner nach BigQuery über eine Dataflow-Vorlage, Reverse-ETL zurück mit EXPORT DATA, oder föderierte Abfragen ganz ohne Kopie. Das Muster, das die eigene Dokumentation beschreibt, ist ein Kreislauf — Spanner bedient die Echtzeitentscheidung, BigQuery findet das historische Muster, und das Label geht zurück nach Spanner und verändert die nächste Entscheidung.

Graph oder Vektor? Falsche Frage

Alle paar Monate wird eine neue Speicherform zum Fundament der KI erklärt und die vorherige stillschweigend degradiert. Vektordatenbanken bekamen das letztes Jahr, Graphen bekommen es jetzt. Beide Rahmungen sind falsch, denn die beiden beantworten unterschiedlich geformte Fragen.

Vektorsuche findet, was ähnlich ist. Sie haben eine Anfrage und wollen die Passagen, die ungefähr dasselbe bedeuten. Ähnlichkeit ist unscharf, gelernt und hat keine Begründung, die Sie jemandem zeigen könnten. Die Mechanik davon habe ich in Brauchst du eine Vektordatenbank und Welches Embedding-Modell behandelt.

Graphtraversierung findet, was verbunden ist. Sie haben einen Startknoten und wollen alles, was über einen definierten Pfad erreichbar ist. Die Beziehung ist explizit, typisiert und prüfbar — Sie können auf genau die Kette von Kanten zeigen, die die Antwort erzeugt hat.

Für das Grounding eines Agenten zählt dieser Unterschied mehr, als beide Lager zugeben. Vektorsuche bringt Sie in die richtige Region des Korpus; sie kann Ihnen nicht sagen, dass dieser Lieferant zwei Sprünge von jener verspäteten Bestellung entfernt ist. Traversierung liefert eine präzise, erklärbare Nachbarschaft; sie findet aus einer vage formulierten Frage nicht den richtigen Einstiegspunkt. GraphRAG ist schlicht die Beobachtung, dass man beides will — semantischer Einstieg, strukturelle Erweiterung.

Deshalb integriert BigQuery Graph Vektor- und Volltextsuche in die Graphoberfläche, statt sie als konkurrierendes Produkt zu behandeln. Die interessanten Systeme des Jahres 2026 nutzen beides in einer Abfrage — genau das, was zu erwarten ist, sobald man aufhört, Speicher-Engines wie Mannschaften zu behandeln.

Das Fazit

Stellen Sie zuerst die Tiefenfrage. Haben Ihre Traversierungen eine bekannte, feste Zahl von Sprüngen, dann haben Sie ein Join-Problem, und ein Property Graph gibt Ihnen ein neues Vokabular für eine Abfrage, die Sie ohnehin schreiben konnten. Ist die Tiefe unbekannt oder erst zu entdecken, kostet SQL Sie seit Jahren Lesbarkeit, und eine Graph-Engine zahlt sich bei der ersten Abfrage aus.

Lautet die Antwort ja, prüfen Sie vor allem anderen die Editionszeile. GQL braucht eine Reservierung mit Enterprise oder Enterprise Plus; On-Demand bekommt GRAPH_EXPAND und sonst nichts. Dieser eine Satz streicht die Option für manche Teams vollständig, und es ist besser, das jetzt zu erfahren als nach dem Review des Datenmodells.

Wählen Sie dann die Last, nicht das Produkt. Millisekunden mit wartendem Nutzer heißt Spanner Graph. Analyse des ganzen Graphen in Minuten heißt BigQuery Graph. Sie teilen eine Sprache, die Entscheidung ist also umkehrbar — selten genug, um es laut auszusprechen.

Und wenn Sie Ihre erste Traversierung schreiben, setzen Sie den Pfadmodus. Der Standard läuft im Kreis, und er sagt es Ihnen nicht.