Unterstützt DynamoDB Volltextsuche?

Nein, nicht nativ. DynamoDB hat keine Volltextsuche: kein Relevanz-Ranking, kein Stemming und keine unscharfe Suche — die eingebauten String-Werkzeuge sind exakte Vergleiche, begins_with auf Sort Keys und contains-Substring-Filter. AWS' Antwort ist die Zero-ETL-Integration mit Amazon OpenSearch Service, die eine Tabelle in einen Suchindex repliziert, für Volltext-, Vektor- und semantische Suche.

Was nativ geht

begins_with auf einem Sort Key — effizientes Präfix-Matching innerhalb einer Partition; das Rückgrat hierarchischer Sort-Key-Modelle.
contains in einer Filter Expression — Substring-Matching, aber Filter laufen nach dem Read, bei einem Scan zahlst du also weiterhin für jedes geprüfte Item. Wann das vertretbar ist, steht im Leitfaden zu Filterstrategien.

Keines von beiden rankt Ergebnisse, verzeiht Tippfehler oder versteht Wortgrenzen — es sind String-Prädikate, keine Suche.

Dieselbe Abfrage, vier Varianten, gemessen

Wir haben 100 Items (84 KB) mit Produkttiteln geladen und die Tabelle viermal gescannt, wobei nur der Suchbegriff geändert wurde:

Filter	`Count`	`ScannedCount`	Read-Einheiten	Treffer
`contains(title, "run")`	3	100	11	Shoes for runs · Trail running shoe · Sneaker, runner grade
`contains(title, "Run")`	2	100	11	Running shoes · Rungs for a ladder
`contains(title, "running")`	1	100	11	Trail running shoe
`contains(title, "runing")`	0	100	11	nichts

Lies diese Zeilen so, wie eine Person sie tippen würde, die etwas in ein Suchfeld eingibt. "run" verfehlt Running shoes und RUNNING SHORTS, weil der Vergleich case-sensitive ist. "Run" holt Running shoes zurück, verfehlt RUNNING SHORTS weiterhin und schleppt Rungs for a ladder mit, weil ein Substring keine Ahnung hat, wo ein Wort anfängt. Keine Schreibweise dieser Abfrage findet alle drei. Lass einen Buchstaben weg, und du bekommst gar nichts, denn es gibt keinen unscharfen Rückfall, auf den degradiert werden könnte.

Die letzte Spalte ist der Teil, der Geld kostet. Jeder Scan hat 11 Read-Einheiten verbraucht, auch der, der nichts getroffen hat, weil der Filter nach dem Read läuft. AWS sagt es unmissverständlich: "A filter expression is applied after a Scan finishes but before the results are returned. Therefore, a Scan consumes the same amount of read capacity, regardless of whether a filter expression is present." Und die eigene Diagnose zu genau diesem Muster: "A high ScannedCount value with few, or no, Count results indicates an inefficient Scan operation."

Der Preis einer Suche folgt also der Größe des Katalogs, nie der Genauigkeit der Abfrage. Häng das an ein Suchfeld mit Vorschlägen beim Tippen, und „running shoes" rechnet die ganze Tabelle dreizehnmal ab, einmal pro Tastendruck, um ein einziges Item zurückzugeben.

Die AWS-native Antwort: Zero-ETL zu OpenSearch

Das DynamoDB-Plugin für OpenSearch Ingestion synchronisiert eine Tabelle in einen oder mehrere OpenSearch-Indizes: Ein erster Snapshot lädt über DynamoDBs S3-Export (PITR erforderlich), danach repliziert DynamoDB Streams Änderungen nahezu in Echtzeit. Die Pipeline verbraucht keinerlei Read- oder Write-Durchsatz deiner Tabelle, sie ist also neben Produktions-Traffic unbedenklich — und AWS gibt an, dass die Integration Volltext-, Vektor- und semantische Suche über deine DynamoDB-Daten ermöglicht.

Tiefer einsteigen

Wenn deine „Suche" in Wirklichkeit ein bekanntes Lookup ist, repariere stattdessen das Modell — die Leitfäden zu Filterstrategien und Sort-Key-Strategien zeigen, was Keys leisten können. Probiere begins_with-/contains-Bedingungen im Expression Builder aus und lade DynoTable herunter, um Live-Tabellendaten beim Erkunden zu filtern.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Die vier Scans wurden am 2026-07-28 gegen DynamoDB Local 3.3.0 mit @aws-sdk/client-dynamodb 3.1095.0 auf Node v24.18.0 ausgeführt. Count, ScannedCount und die Read-Einheiten sind die eigenen Zahlen der Engine.