DynamoDB adds native vector search and removes the separate vector store
AWS has announced general availability of native vector search in DynamoDB, where embeddings live alongside operational data and a SearchVectors API returns nearest neighbors. If your data already lives in DynamoDB, this is the end of the sync pipeline to a dedicated vector store.
August 5, 2026. AWS announces general availability of vector search in Amazon DynamoDB. You can now store embeddings next to your operational data, in the same table, and query nearest neighbors with a SearchVectors API — without replicating anything to a separate vector database. It removes an entire architecture: the hand-synchronized vector store. For teams already inside the AWS ecosystem, that is one database fewer to secure, back up, and pay for — and one fewer set of credentials to rotate. It is the same argument that pushed DynamoDB itself over self-managed databases a decade ago, now applied to vectors.
The dominant pattern of the last three years was awkward. Data lived in DynamoDB, vectors in OpenSearch, Pinecone, or pgvector, and a sync pipeline copied continuously between the two. Three costs piled up: maintaining the pipeline, moving data (billed), and end-to-end latency. DynamoDB’s pitch fits in one line: vectors and attributes share the same serverless infrastructure and the same pay-per-request model.
What the GA actually does
The mechanism is easy to describe. You generate embeddings with the model of your choice — Amazon Bedrock Titan Text Embeddings, Cohere Embed, or an OpenAI model — and store them in a List attribute of numbers, with no new type and no schema change. You then create a vector index on that attribute, specifying three things: the number of dimensions, the distance function, and any filter attributes.
Querying goes through SearchVectors: you pass a query vector, the result count (Top K, capped at 100), and optional filter conditions. The response returns the closest items, ranked by similarity score, with their operational attributes in the same call.
The technical bounds matter before you choose. Up to 4,096 dimensions, three distance functions — Euclidean, cosine, and dot product — and single-digit millisecond latency with 99%+ recall, advertised as valid “even to trillions of vectors.” The inline filter supports exact-match only: no BETWEEN, no BEGINS_WITH.
The keystone: the partition key
One architectural detail sets this implementation apart from a generic vector store: the vector index can carry a partition key. Each search is then scoped to a single partition key value, which avoids scanning the whole index and keeps latency predictable at scale.
The documentation’s example is telling: a product catalog serving multiple marketplaces indexes its descriptions, with marketplace as the partition key. A search for “lightweight running shoes for summer” then runs within one marketplace, filtered by category = footwear, never touching the rest of the index. It is the same partitioning logic as the rest of DynamoDB — and it is what lets the service “scale horizontally” without degrading latency.
The practical consequence: the partition key is optional but recommended once vector volume or query throughput grows. Without it, every SearchVectors must traverse the full vector set — which works, but costs more and answers slower as the index grows.
The real trade-off: one foundation or a specialist
The question is not “does it work” — it does — but “where does the specialist still win.” Three cases still favor a dedicated vector store.
First, hybrid search. OpenSearch and the specialized engines combine full-text and vector in a single query, with reranking and fused scores. DynamoDB does pure vector similarity; if your use case needs “keyword + semantic,” you’ll be running two systems anyway.
Second, rich filtering. DynamoDB’s inline filter is exact-match only; an engine like OpenSearch or pgvector with HNSW or IVF indexes offers range predicates, facets, and nested metadata that are far richer.
Third, recall tuning. Specialized vector stores let you drive the ANN parameters — HNSW graph size, candidate counts, the precision/latency trade-off. DynamoDB locks those knobs behind its SLA: that is the price of zero operations, but also a loss of control for teams that tune finely.
The use cases it fits
The feature targets one pattern above all: data that is already operational and now needs a semantic access path. AWS names four — agentic memory, retrieval-augmented generation, recommendation engines, and anomaly detection. What they share is a need for similarity over embeddings that sit right next to the attributes they describe: a product row and its description embedding, a user profile and its preference vector, a session and its risk embedding.
For those cases the alternative has always been a second system. That is the point of the launch: the more your vectors are just another attribute of a record, the less sense a separate vector database makes. The sync pipeline was never the goal — it was the tax you paid to keep two systems honest.
Where it sits in the AWS lineup
DynamoDB is not the first AWS service to do vector similarity, and you should know when to prefer the others. Amazon OpenSearch Serverless remains the natural home for hybrid search — full-text and vector combined — and for cases where reranking and relevance metrics matter. Amazon Bedrock Knowledge Bases abstracts the whole RAG chain: ingestion, chunking, embeddings, and retrieval, without you ever seeing the underlying store.
What’s new with DynamoDB is that it brings vectors into the operational database itself. Where OpenSearch adds a cluster to operate and Bedrock adds an abstraction, DynamoDB adds an index. For a team that wants semantics without a new infrastructure component, it’s the quietest option.
The hidden cost: consumption
The serverless model has a flip side: every SearchVectors consumes capacity units, and reading a vector index can cost far more than a plain GetItem, because it touches several partitions. Add the index storage, billed in proportion to the number of vectors.
Before rolling it out, measure on a real scope: cost per query, monthly storage, and the bill for writing embeddings — which must be generated and then written, potentially in bulk during a backfill. A badly sized vector index can turn a “serverless” feature into a surprise invoice.
Verdict
If your operational data already lives in DynamoDB, native vector search is the obvious choice: you remove a vector store, a sync pipeline, and a data-movement bill, while keeping a serverless model with no machines to manage. That covers RAG over a catalog, agent memory, or a recommendation engine on data already hosted there.
If you need hybrid search, rich filtering, or tunable recall, stay on OpenSearch, pgvector, or a specialized vector store — and accept the operational load that comes with it. DynamoDB does not replace them on that ground.
Before committing a large volume, check the vector index storage pricing on the pricing page: the pay-per-request model is appealing, but an index over billions of vectors is not free to host. The right reflex is to prototype on a real scope and measure cost per query, not just latency.