DynamoDB vector search goes GA, folding similarity lookup into AWS's NoSQL workhorse
AWS has made DynamoDB vector search generally available, putting similarity search on the same serverless infrastructure that already carries much of the world's operational NoSQL data. The feature went live on August 5, 2026 in every commercial AWS Region and in GovCloud (US), shipping straight to GA with no public preview and no separate database to stand up.
Developers write embeddings as a list of floats on an ordinary item attribute, generated with models such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text embedding models, then query them through the new SearchVectors API. A standard PutItem call is all it takes to land a vector next to the operational record it belongs to. The service runs approximate nearest neighbor (ANN) searches with single-digit millisecond latency at 99%+ recall, and AWS says the design holds even at trillions of vectors, with vector indexes carrying no storage limit and scaling horizontally as data grows.
How DynamoDB vector search works
Until this release, teams that wanted semantic retrieval had to copy data out of DynamoDB into a dedicated vector database and keep a synchronization pipeline running between the two systems. That arrangement piled on operational overhead, data movement costs, licensing costs, and latency predictability problems, because the copied index could drift from the source of truth. The new capability keeps embeddings and operational data in one place under a single pay-per-request pricing model, removing the replication step entirely.
Indexes support up to 4096 dimensions and three distance functions: Euclidean, cosine, and dot product. A single SearchVectors call returns up to 100 results, and queries can be scoped with an optional partition key so searches stay inside a logical slice of the table. The partition key option matters for multi-tenant setups, where searches limited to one user or tenant slice keep latency predictable without touching the rest of the data. Inline filtering on non-vector attributes works for exact matches, though range conditions such as BETWEEN are not part of the initial release, a gap teams doing numeric-window queries will notice.
| Dedicated vector database (previous route) | DynamoDB vector search (GA) | |
|---|---|---|
| Where data lives | Second store holding a copy of operational data | Embeddings stored on items in the source table |
| Replication | Continuous sync pipeline to maintain | None |
| Added costs | Data movement, licensing, separate infrastructure | Metered vector writes, searches, and index storage |
| Commitment | Separate store to size and pay for | Pay-per-request, no monthly commitment |
| Latency | Replication lag can hurt predictability | Single-digit ms at 99%+ recall |
AWS points the feature at semantic retrieval over agentic memory, retrieval augmented generation, recommendation engines, product similarity, personalized advertising, and anomaly detection. The agentic memory case is the most direct fit: DynamoDB already stores the conversation history and state that AI agents work with, and vector search adds semantic recall over that memory so agents can ground their next action in what happened earlier rather than replaying a fixed transcript. The same logic applies to retail and ad tech, where product catalogs and event data already sit in the table; embedding them in place turns the existing store into the source for similarity-based recommendations without a second copy of the catalog.
What the GA changes for RAG and agentic workloads
Operationally, DynamoDB vector search inherits everything the database already is: no servers to provision, patch, or manage, no software to install, no versions, no maintenance windows, and zero downtime for upgrades. Vector operations are metered separately from core table usage, with dedicated charges for vector writes, searches, and index storage, and the pricing carries no monthly commitment. That matters for experimentation: a prototype index that receives a handful of queries a day costs a handful of query charges, where a separate store typically means standing up infrastructure that bills whether or not it is used.
The latency and recall claims deserve a closer look. The hard part of vector search at scale is that speed, scale, and accuracy pull against each other: as datasets grow into the billions or trillions of vectors, latency traditionally climbs unless you accept lower recall or lower throughput. Because DynamoDB's implementation runs approximate nearest neighbor search rather than an exact scan, it can hold similarity lookups in single-digit milliseconds while keeping recall at 99%+, the combination that has historically separated purpose-built engines from bolt-on approaches.
The strategic read is that AWS has collapsed the standalone vector database layer into its most widely deployed operational store. Vector databases emerged as a separate category largely because mainstream operational databases lacked native similarity search, so teams accepted a second system, a sync job, and a second bill to get embeddings-based retrieval. DynamoDB vector search removes that justification for a large class of workloads and pressures dedicated vendors on two fronts at once: cost, since pay-per-request on shared infrastructure undercuts a separate metered store, and operational simplicity, since there is nothing left to replicate or reconcile.
The clearest beneficiaries are teams with DynamoDB-centric architectures that want one AI feature: semantic search over data they already hold. Previously each of those teams stood up a second store, maintained a replication job, and paid a second invoice for a single workload; the native capability removes all three obligations and leaves the decision to be made on query semantics alone.
For teams already running RAG pipelines on DynamoDB, the practical change is deleting the extraction job that copies items into a vector store and pointing queries at the source table, which eliminates a class of consistency bugs where the search index lagged behind operational data. For agentic workloads, the latency profile matters in a specific way: single-digit millisecond similarity lookups at high recall are the difference between an agent that fetches memory inline during a step and one that needs precomputed or cached context. State, embeddings, and query results now live in one system with one consistency model and one bill, instead of two stores that must be kept aligned. The trade-offs are real, though: filtering is limited to exact matches in this release, and the 100-result Top K cap means applications that want large candidate sets for reranking will still route through another engine.
The rollout itself carried little ceremony. Going straight to GA with no public preview is unusual for a feature of this scope, and shipping simultaneously to every commercial region plus GovCloud (US) removes the region-by-region migration window teams normally plan around.
DynamoDB has anchored AWS's NoSQL story since 2012, built for predictable performance at high throughput across serverless web and mobile apps, gaming, ad tech, IoT, and retail. Adding vector search to that base lands the capability exactly where the operational data already lives, which is the core of the argument: AWS is betting that most teams would rather search where their data is than move their data to where search lives.
Why this matters
For developers, similarity search stops being a second system and becomes an attribute of the database they already run, which drops the cost and complexity of RAG and agentic memory in one move. For the vector database market, it is a pricing and simplification signal that dedicated stores will need to answer with differentiated capabilities, because the default choice for new DynamoDB-centric workloads just shifted.
Sources
Amazon DynamoDB now supports real-time vector search at any scale
Amazon DynamoDB now supports real-time vector search
Related Articles
- AWS Rebuilds Amazon OpenSearch Serverless for Agentic AI and Dynamic Workloads
- MongoDB 8.3 Debuts with Automated Voyage AI Embeddings for Production GenAI
- AWS Integrates Kiro AI Agent for Natural Language Querying in Amazon Redshift
✔Human Verified
Researched and cross-referenced against primary sources by the Bytevyte editorial team. This article was generated with the assistance of artificial intelligence and reviewed by the Bytevyte editorial team.