DynamoDB adds native vector search, and the RAG stack on AWS loses a moving part
AWS has made vector search native to DynamoDB, generally available since August 5. For teams already on the database it removes the need for a separate vector store kept in sync, though exact-match-only filtering and cost tuning are real caveats.
AWS has made vector search a native capability of DynamoDB, generally available since August 5 across all commercial regions and GovCloud (US). For teams already running the database as their application store, the practical change is that semantic search over that data no longer requires a second, separate vector database kept in sync. The feature arrives after most rival databases already shipped their own vector support, so the interesting question is less whether it works and more where it changes the build decision.
What shipped
DynamoDB now supports a new index type built on attributes that hold vector
embeddings. Developers generate those embeddings with a model, which AWS points
to Amazon Bedrock Titan, Cohere, or OpenAI for, store them as floats through
ordinary PutItem calls, and query them with a new SearchVectors API that
takes a query vector, returns up to 100 ranked results, and accepts optional
filter conditions. AWS lists support for up to 4,096 dimensions, three distance
functions (Euclidean, cosine, and dot product), and single-digit millisecond
latency at 99 percent-plus recall across what it describes as trillions of
vectors. This is generally available, not a preview.
Why it matters to a working developer
The concrete win is architectural. Before this, a team on DynamoDB that wanted semantic search or retrieval-augmented generation (RAG, where an app fetches text by meaning to feed a language model) had to run a dedicated vector store beside it and build a pipeline to keep the two in sync. Native vector search removes that second system and the synchronization code around it, which is usually where the operational bugs live. Application data and its embeddings sit in one table, under one pay-per-request billing model, with no extra cluster to provision. For anyone whose primary data already lives in DynamoDB, that collapses a two-database design into one.
The catch is filtering and cost
The trade-offs are real and worth reading before committing. InfoQ’s coverage notes that inline filtering on non-vector attributes only supports exact-match conditions, with no range operations, which rules out common patterns like “vectors from the last 30 days” without a workaround. Developers in that coverage also flagged that it is not spelled out whether DynamoDB applies attribute filters before or after the vector search, and that ordering changes both result quality and cost. On price, AWS’s own guidance is to keep dimensions low, minimize index projections, exclude the stored embeddings from query results, and partition selectively, all of which reads as a warning that a naive configuration gets expensive. One practitioner cited by InfoQ argued the workload might land cheaper on object storage than on DynamoDB at large scale.
Late, but that is not the whole story
DynamoDB is arriving well behind the field. Postgres has had pgvector for years, MongoDB Atlas shipped vector search, and Redis added it too, a point InfoQ frames as the “too late to the party” critique from some practitioners. Lateness matters less, though, when the deciding factor is proximity to existing data. The database-plus-vectors convergence has been the clear direction across the market, and the same logic that made Databricks fold Electric into Neon to give agents a local Postgres is at work here: teams would rather keep search next to the records than run a specialized engine for it. AWS is not competing on novelty. It is betting that the DynamoDB install base picks the option that adds no new system.
For technical decision-makers, the honest read is narrow and useful. If your data already lives in DynamoDB and your filtering needs are simple, native vector search is a straightforward way to delete a component from your stack. If you need rich metadata filtering, tight latency guarantees, or the lowest cost per vector at very large scale, a dedicated store is still the safer call, and this release does not change that. The signal worth watching over the next quarter is whether AWS closes the filtering gap and publishes clearer cost math, because that, not the launch itself, decides how far the feature travels. Stackmaven will check back on or around November 16.