Amazon ElastiCache Serverless for Valkey erhält Vektor-, Volltext- und Hybridsuche samt Aggregationen: Valkey 9 erforderlich; AWS nennt eine Latenz von „nur wenigen Mikrosekunden“, Vektor-Recall „bis zu 99 %“ und „Milliarden Abfragen pro Tag“, hier nicht geprüfte Herstellerangaben ohne genannte Datengröße, Hardware oder Preise

Am 10. November 2026 hat AWS mitgeteilt, dass Amazon ElastiCache Serverless for Valkey jetzt Vektor-, Volltext- und Hybridsuche sowie Aggregationen unterstützt. Die Meldung beschreibt das Problem, auf das sie zielt: Anwendungen, die Live-Daten durchsuchen, stehen vor einem harten Zielkonflikt zwischen Latenz und Recall, und Aktualisierungen brauchen oft Zeit, bis sie durchsuchbar sind. Dieser Bericht stützt sich auf die AWS-Meldung und auf die Seite „Getting started with Search“ im ElastiCache-Benutzerhandbuch. Alle Geschwindigkeits- und Recall-Angaben auf beiden Seiten sind Aussagen von AWS. Keine Seite nennt einen Datensatz, eine Vektorgröße, Hardware oder eine Testmethode; dieser Bericht behandelt sie daher als eingeschränkte Behauptungen von AWS, die er nicht getestet hat, und nicht als Messergebnisse.

Die Meldung macht drei Leistungsaussagen. Die Suche kann „mit einer Latenz von nur wenigen Mikrosekunden bei bis zu 99 % Recall für die Vektorsuche“ laufen; sie kann „Milliarden von Abfragen pro Tag“ bedienen; und Aktualisierungen sind „in nur wenigen Mikrosekunden, sobald Schreibvorgänge abgeschlossen sind“ durchsuchbar. Die erste und die dritte tragen eine Einschränkung, die zweite nicht. „Nur wenige“ beschreibt einen Bestfall, keine typische oder garantierte Zahl. „Bis zu 99 % Recall“ ist eine Obergrenze, und Recall ist der Anteil der wahren nächsten Nachbarn, den die Suche findet; er schwankt mit Indexeinstellungen und Daten. „Milliarden von Abfragen pro Tag“ ist eine Kapazitätsaussage ohne genannte Testbedingungen; sie ist weder eine genannte Grenze noch ein Tageskontingent. Das Handbuch ergänzt, ElastiCache for Valkey biete „die Vektorsuche mit der niedrigsten Latenz, dem höchsten Durchsatz und dem besten Preis-Leistungs-Verhältnis bei 95 % und mehr Recall unter gängigen Vektordatenbanken auf AWS“, ohne Vergleichsdaten auf der Seite. Die Meldung sagt, man könne den Recall nach Bedarf einstellen, was bedeutet, dass der Zielkonflikt zwischen Geschwindigkeit und Recall bleibt und nun eine Einstellung ist, die man selbst wählt.

Zu den Funktionen nennt das Handbuch Echtzeit-Volltextsuche, exakte Suche auf Tags, Suche in Zahlenbereichen, Vektorsuche und Hybridsuche. Die Meldung sagt, man könne Suchtypen in einer Abfrage kombinieren und Ergebnisse mit serverseitigen Aggregationen auswerten. Welche Kombinationen, Operatoren oder Befehle unterstützt werden und ob sie sich je nach Engine-Version unterscheiden, sagen die beiden Seiten nicht. Das Handbuch verweist dafür auf die eigenen Seiten „Search features and limits“ und „Command Reference“, die dieser Bericht nicht gelesen hat. Die Meldung nennt Einsatzzwecke wie Produktentdeckung, Empfehlungssysteme und Retrieval-Augmented Generation. Laut Handbuch ist die Vektorunterstützung für Embeddings von Anbietern wie Amazon Bedrock, Amazon SageMaker, Anthropic oder OpenAI gedacht und dafür, Milliarden hochdimensionaler Vektoren mit bis zu 99 % Recall zu indexieren, zu durchsuchen und zu aktualisieren. „Milliarden“ ist eine Entwurfsaussage; die Seiten nennen weder eine getestete Größe noch Kosten oder Speicherbedarf.

Die Meldung bewirbt die Funktion auch für KI-Agenten. Sie sagt, Entwickler könnten jedem Agenten, jeder Sitzung oder Aufgabe einen eigenen Datenspeicher für Gedächtnis und Kontextabruf geben, sodass Agenten experimentieren, scheitern und es erneut versuchen können, ohne Produktion oder einander zu berühren. Jeder Datenspeicher sei in Sekunden bereit, über einen öffentlichen Endpunkt ohne Netzwerkeinrichtung erreichbar und werde nur nach Nutzung abgerechnet, ohne zu verwaltende Infrastruktur. Ein öffentlicher Endpunkt ist bequem. Die Meldung beschreibt nicht, wie der Zugriff darauf kontrolliert wird, und ein Sicherheitsteam sollte die ElastiCache-Dokumentation zu Authentifizierung und Verschlüsselung lesen, bevor es ihn für Agentengedächtnis nutzt, das sensible Texte enthalten kann. Dieser Bericht hat diesen Teil nicht gelesen.

Die Versionsbedingungen sind die Kernfakten. Die Meldung sagt, die Suche sei auf ElastiCache Serverless for Valkey in Version 9 verfügbar, in allen kommerziellen AWS-Regionen, den AWS-GovCloud-(US)-Regionen und der Region AWS European Sovereign Cloud. Man erstellt einen neuen Serverless-Cache oder aktualisiert einen bestehenden auf Valkey 9, mit der AWS-Verwaltungskonsole, dem SDK oder der CLI. Das Handbuch zeichnet ein breiteres Bild: Die Suche funktioniert auf knotenbasierten Clustern mit Valkey 8.2 oder neuer und auf ElastiCache-Serverless-Caches mit Valkey 9.0 oder neuer. Das sind Mindestversionen für die Suche; die Seiten zeigen nicht, dass jede Suchfunktion auf jeder Version gleich ist. Ein bestehender Cache auf einer älteren Engine-Version muss also zuerst aktualisiert werden, und die Seiten beschreiben nicht, was das bedeutet. Die Meldung beschreibt Valkey als „die freizügigste Open-Source- und herstellerneutrale Alternative zu Redis und die empfohlene Engine für ElastiCache“. Das ist AWS' Beschreibung der eigenen Empfehlung.

Das Handbuch nennt unter der Suche drei Unterthemen: Funktionen und Grenzen, Wahl der passenden Konfiguration und Drosselung von Suchschreibvorgängen. Das letzte zählt. Ein Cache, der durchsuchbare Daten aktualisiert, sobald Schreibvorgänge abgeschlossen sind, muss sich unter hoher Schreiblast schützen, und ein Drosselungsthema deutet darauf hin, dass Grenzen gelten. Die hier erfasste Seite erklärt sie nicht; die Aussage, Aktualisierungen seien durchsuchbar, „sobald Schreibvorgänge abgeschlossen sind“, sollte daher bei der eigenen Schreibrate getestet werden. Das Handbuch sagt außerdem, für Agenten-Workflows gebe es einen „ElastiCache Skill“ und einen Valkey-MCP-Server, die Indizes verwalten, Vektor-Embeddings erzeugen und ein einheitliches Suchwerkzeug bieten. Dieser Bericht hat sie nicht getestet.

In den Quellen fehlt einiges. Es gibt keinen Preis: Die Meldung verweist auf die Preisseite. Es gibt keine Benchmarks mit angegebener Datenmenge, Vektordimension oder Hardware, keinen Vergleich mit anderen Vektordatenbanken über AWS' eigene Aussage hinaus und keine Beschreibung des Speicherbedarfs pro Million Vektoren. Ein Team, das dies mit einem separaten Such- oder Vektorspeicher vergleicht, sollte einen eigenen Test mit echten Vektoren, Filtern und der eigenen Schreibrate fahren, den Recall bei der benötigten Latenz messen und die Kosten mit der Preisseite vergleichen. Der praktische Gewinn, falls die Aussagen tragen, ist, schnelle Schlüssel-Wert-Daten und Suche in einem Dienst zu halten. Die Seiten beweisen nicht, dass sie tragen.