Google Cloud hat den ScaNN-Index von AlloyDB aktualisiert; die offizielle Obergrenze liegt jetzt bei über 10 Milliarden Vektoren. In diesem Maßstab liegen die gemessenen Werte bei einer P95-Latenz von höchstens 51 Millisekunden und einem Recall von 95 Prozent. AlloyDB ist der verwaltete Datenbankdienst von Google Cloud mit PostgreSQL-kompatibler Schnittstelle.
Die Änderung betrifft die Indexstruktur. Bisher organisierte ScaNN Vektoren über zwei- oder dreistufige Bäume, jetzt kommt eine vierte Ebene hinzu.
Eine Ebene mehr im Baum, zwei Größenordnungen weniger Suchaufwand
Die ungefähre Nächste-Nachbarn-Suche gruppiert Vektoren zunächst nach Ähnlichkeit in Cluster, die in Ebenen organisiert sind. Bei einer Abfrage wird von der obersten Ebene abwärts gegangen, wobei auf jeder Ebene nur die nächstliegenden Zweige weiterverfolgt werden. Die Anzahl der Ebenen bestimmt die Suchkomplexität: Ein zweistufiger Baum liegt bei O(N^1/2), ein dreistufiger sinkt auf O(N^1/3), ein vierstufiger drückt sie weiter auf O(N^1/4).
Bei einer Größenordnung von zehn Milliarden liegen diese Exponenten weit auseinander. Grob gerechnet: Bei N gleich 10 Milliarden liegt die Quadratwurzel von N bei rund 100.000, die dritte Wurzel bei rund 2.150, die vierte Wurzel bei rund 316. Die Anzahl der Kandidaten, die eine einzelne Abfrage berühren muss, fällt damit von der Hunderttausender- auf die Dreihunderter-Größenordnung. Genau daher stammt der Wert von 51 Millisekunden.
Zu den konkreten Maßnahmen, die Google nennt, zählen eine Top-K-Verzweigungsstrategie, der SOAR-Algorithmus, Anpassungen der Cluster-Zentroide und der Aufbau balancierter Bäume, dazu dynamisches Sampling, um Speichergrenzen zu umgehen. Google benennt zwei Engpässe der alten Struktur: Wird der Baum größer, steigt der Rechenaufwand sowohl beim Indexaufbau als auch beim Durchlaufen der Abfrage; und beim Sampling von zehn Milliarden Vektoren lässt sich der verfügbare Speicher leicht ausschöpfen.
KI-Agenten haben das Datenvolumen nach oben getrieben
Laut Google treibt die Nachfrage aus unternehmensweiten KI-Agenten-Anwendungen die Anwendungsfälle in Richtung mehrerer Milliarden Vektoren, wobei die zugrunde liegenden Vektordatenbanken damit häufig überfordert sind.
Dieser Satz benennt die Quelle der aktuellen Skalierung. In klassischen RAG-Szenarien zerlegt ein Unternehmen seine internen Dokumente in Fragmente, meist in einer Größenordnung von zehn bis hundert Millionen. Bei KI-Agenten ist das anders: Bei jedem Ausführungsschritt müssen sie auf den Verlauf zurückblicken, Tool-Beschreibungen nachschlagen und Nutzerpräferenzen abrufen – eine einzelne Aufgabe kann so ein Dutzend oder mehr Abfragen auslösen. Auch die Datenquellen haben sich von Dokumenten auf Konversationsprotokolle, Aktionslogs und Zwischenergebnisse ausgeweitet, die täglich weiter anwachsen.
Noch eine Rechnung: Bei einer P95 von 51 Millisekunden kostet eine Agenten-Aufgabe mit 15 Abfragen allein in der Vektordatenbank rund 0,77 Sekunden. Das ist nur der Datenbank-Anteil – Modellinferenz, Tool-Aufrufe und Netzwerk-Roundtrips kommen noch hinzu. Die Abfragelatenz wirkt bei einer einzelnen Interaktion unbedeutend, summiert sich aber in einer mehrstufigen Kette spürbar auf.
Universelle Datenbanken übernehmen zunehmend spezialisierte Produkte
Dass die Vektorsuche im Zehn-Milliarden-Maßstab in einen PostgreSQL-kompatiblen Managed Service eingebaut wird, weist in dieselbe Richtung: Vektoren brauchen keine eigene, separate Infrastruktur mehr.
Für Unternehmenskunden rechnet sich das leicht. Die Geschäftsdaten liegen ohnehin schon in relationalen Datenbanken – Nutzertabellen, Bestelltabellen, Berechtigungsregeln sind bereits dort. Vektoren in einer separaten Spezialdatenbank zu halten bedeutet zwei Backup-Systeme, zwei Berechtigungssysteme, zwei Konsistenzgarantien und die Notwendigkeit, Transaktionsgrenzen über beide Systeme hinweg selbst zu handhaben. Lässt sich das Problem stattdessen mit einem zusätzlichen Index in der bestehenden Datenbank lösen, halbiert sich der Betriebsaufwand direkt.
Auch die Position spezialisierter Vektordatenbanken hat sich in den vergangenen zwei Jahren verschoben. Sie haben weiterhin Vorteile bei extremer Performance und bei der Geschwindigkeit, mit der neue Suchalgorithmen umgesetzt werden, doch universelle Datenbanken heben die Schwelle des Ausreichenden immer weiter an – von Millionen über Hunderte Millionen bis jetzt zu zehn Milliarden. Der verbleibende Raum für spezialisierte Produkte schrumpft auf jenen kleinen Bereich mit den härtesten Anforderungen an Latenz und Durchsatz.
Diesmal hat Google für AlloyDB weder Partitionsanzahl noch Vektordimension, Indexaufbauzeit oder ein QPS-Limit veröffentlicht. Gerade diese Kennzahlen sind bei der praktischen Auswahl oft aussagekräftiger als der Spitzenwert der Skalierbarkeit – besonders die Dauer des Indexaufbaus, denn die Kosten eines Neuaufbaus im Zehn-Milliarden-Maßstab können unverhältnismäßig hoch ausfallen.
Quellen: offizieller Google-Cloud-Blog, AlloyDB-ScaNN-Indexdokumentation, CocoLoop; Angaben zu Vektorskala, P95-Latenz und Recall gemäß offizieller Ankündigung, Komplexitätsumrechnungen sind redaktionelle Schätzungen.