Was AWS angekündigt hat

Am 5. August 2026 gab AWS bekannt, dass Amazon DynamoDB Vektorsuche nun nativ verarbeitet, ohne dass ein separater Vektorindex aufgebaut oder gepflegt werden muss. Das Unternehmen spricht von einer Latenz im einstelligen Millisekundenbereich bei einer Trefferquote von über 99 Prozent, skalierbar auf Billionen von Vektoren. SiliconANGLE und InfoWorld berichteten unabhängig voneinander noch am selben Tag und beschrieben die Funktion als native Fähigkeit statt als aufgesetzten Dienst.

Der Mechanismus ist einfach: Die Vektorsuche läuft jetzt auf derselben Tabelle, die bereits die primären Anwendungsdaten speichert. Es gibt keine zweite Datenbank, die bereitgestellt werden muss, keinen Export-und-Import-Schritt und keine Pipeline, die einen separaten Vektorindex mit den Änderungen in der Quelltabelle synchron halten muss.

Genau dieser letzte Punkt verdient Aufmerksamkeit. Der Wegfall der Synchronisationspipeline beseitigt die Verzögerung zwischen einer Aktualisierung eines Datensatzes und deren Erscheinen in den Suchergebnissen, und er beseitigt jene ganze Klasse von Fehlern, die entsteht, wenn zwei Datenspeicher auseinanderdriften.

Die Anbieterkategorie, die dadurch bedroht ist

In den vergangenen zwei bis drei Jahren bedeutete das Hinzufügen von semantischer Suche oder Retrieval-Augmented Generation zu einem Produkt meist, eine zweite, eigens dafür gebaute Vektordatenbank neben der Datenbank einzuführen, die bereits die eigentlichen Daten hält. Pinecone, Weaviate und Milvus haben ihr Geschäft genau auf dieser Lücke aufgebaut, und Postgres-Erweiterungen deckten denselben Bedarf für Teams ab, die bei einer einzigen Engine bleiben wollten.

Dieses Muster wurde fast zu einem festen Posten in KI-Projektplänen: Budget für einen Vektordatenbank-Anbieter, Budget für Entwicklungszeit für eine Synchronisationspipeline und Budget für eine zweite Sicherheitsprüfung, weil Nutzerdaten nun durch einen zweiten Auftragsverarbeiter fließen. Keiner dieser Kosten war exotisch, aber alle galten als notwendig.

Was AWS am 5. August ausgeliefert hat, löscht diese Anbieterkategorie nicht, entzieht ihr aber in einem großen, häufigen Fall die automatische Rechtfertigung: jedes Team, dessen primäre Anwendungsdaten bereits in DynamoDB liegen. Für diese Gruppe muss der Fall für eine separate Vektordatenbank nun neu begründet werden, statt einfach vorausgesetzt zu werden.

Was vor der nächsten Freigabe eines KI-Projekts zu prüfen ist

Die praktische Anweisung ist einfach und unmittelbar. Bevor ein Vertrag mit einem Vektordatenbank-Anbieter unterschrieben wird und bevor ein Entwickler mit dem Bau einer Synchronisationspipeline von DynamoDB zu einer Vektordatenbank beauftragt wird, sollte jemand prüfen, ob DynamoDB selbst die Aufgabe inzwischen erledigen kann.

Das gilt besonders für bereits geschriebene Pläne. Jeder KI-Projektplan der letzten zwei Jahre, der eine Zeile für 'separate Vektordatenbank hinzufügen' enthält, wurde unter Bedingungen verfasst, die AWS für DynamoDB-Nutzer gerade verändert hat. Diesen Plan erneut zu öffnen kostet einen Nachmittag; ihn nicht zu öffnen kostet einen Anbietervertrag und eine Wartungspipeline, die vielleicht nicht nötig gewesen wäre.

Die Prüfung selbst ist eng gefasst: Liegen die primären Anwendungsdaten bereits in DynamoDB, und liegen der geforderte Maßstab und die geforderte Latenz innerhalb dessen, was AWS veröffentlicht hat? Wenn beide Antworten Ja lauten, wird die separate Vektordatenbank zur Option statt zur Voraussetzung.

Wo eine separate Vektordatenbank weiterhin sinnvoll ist

Nichts davon bedeutet, dass jede eigene Vektordatenbank ausgebaut werden sollte. Teams, die in extrem großem Maßstab oder über mehrere Cloud-Anbieter hinweg arbeiten, haben womöglich weiterhin Gründe, die nichts mit der neuen Fähigkeit von DynamoDB zu tun haben.

Architekturen, die bereits stabil um Pinecone, Weaviate oder Milvus herum aufgebaut sind, müssen sich wegen einer einzelnen Ankündigung ebenfalls nicht ändern. Eine Migration hat ihre eigenen Kosten, und ein funktionierendes System, das seine Anforderungen erfüllt, muss nicht automatisch angetastet werden.

Die ehrliche Position lautet: Das ist eine erneute Prüfung, kein Zwang. Manche Teams werden die Prüfung durchführen und ihre separate Vektordatenbank behalten, weil sie dafür einen echten Grund haben. Der Fehler wäre, gar nicht zu prüfen und aus Gewohnheit bei der alten Annahme zu bleiben.

Worauf als Nächstes zu achten ist

Die unmittelbarste Folge für Datenschutzteams in der EU und im Vereinigten Königreich ist eine Compliance-Frage: Jedes Team, das seine Vektorsuche in DynamoDB verlagert, entfernt einen zweiten Auftragsverarbeiter und eine zweite Datenschutz-Vereinbarung aus seiner Anbieterprüfung, weil Nutzerdaten nicht mehr durch einen separaten Vektordatenbank-Anbieter fließen müssen.

Es lohnt sich zu beobachten, wie die eigenständigen Vektordatenbank-Anbieter reagieren. Eine solche Fähigkeit, ausgeliefert von dem Anbieter, der bereits einen großen Teil der zugrunde liegenden Daten hält, ist die Art von Schritt, die Wettbewerber meist zwingt, sich entweder deutlich zu differenzieren oder stärker über den Preis zu konkurrieren.

Ebenso lohnt es sich zu beobachten, ob andere große Cloud-Datenbankanbieter in den kommenden Monaten ähnliche Vektorfähigkeiten in ihre eigenen primären Datenbanken einbauen. Wird der Schritt von AWS anderswo nachgeahmt, veraltet die Annahme, dass KI-Funktionen eine separate Datenbank benötigen, weit über DynamoDB hinaus.

Weiterlesen: Der Auftragsbestand war 1,5 Milliarden. Die Anleihe auch.  |  Der Knappheitsgewinn ging als Rückkauf