DynamoDB can now search vectors natively. AWS made it generally available on August 5, 2026, across every commercial region and GovCloud on day one. If you maintain a separate Pinecone instance or a pgvector sidecar just to handle semantic search over data that lives in DynamoDB — that extra layer is now optional. Embeddings go directly into your DynamoDB table. You query them with a new SearchVectors
API. No synchronization pipeline. No second database subscription. No drift.
How It Actually Works #
Vectors are stored as a list of floats on your existing DynamoDB items. You create a vector index specifying dimensions (up to 4,096), a distance function — Euclidean, Cosine, or Dot product — and optionally a partition key that scopes searches to a subset of your data. When a write lands on the table, DynamoDB asynchronously updates the index. When you call SearchVectors
, you get back the top-K nearest neighbors, ranked by similarity, with single-digit millisecond latency at 99% recall.
The API itself is minimal:
response = dynamodb.search_vectors(
TableName='Products',
IndexName='ProductVectorIndex',
SearchVector=[{'N': str(v)} for v in query_embedding],
TopK=5
)
You need boto3 1.43.64 or later to access the new APIs. Embeddings are excluded from results by default — you only pay to retrieve them if you explicitly project them back. That is a sensible default that saves real money at scale.
The Architecture Before and After #
Before August 5, the standard stack for DynamoDB shops that needed semantic search looked like: write to DynamoDB, trigger a Lambda or Streams processor, generate embeddings, push to Pinecone or pgvector, and hope nothing drifts. Every schema change required double maintenance. Every outage investigation asked which database was wrong. Analyst Brad Shimmin of Futurum Research summarized the previous approach as “a high-stakes plumbing operation built on nothing more than solder and duct tape.”
The new stack is just DynamoDB. One table, one billing plane, one set of IAM policies. For teams already running DynamoDB, removing an entire infrastructure tier is not a minor convenience — it is a genuine reduction in operational surface area.
Limitations Worth Knowing Before You Migrate #
Native vector search is not unconditionally better than a dedicated vector database. There are real constraints.
On-demand billing mode required. If your table uses provisioned capacity, you cannot add vector indexes. You will need to switch billing modes first, which changes your cost model and may not suit high-throughput predictable workloads.
Eventual consistency. The vector index is updated asynchronously. A freshly written item might not appear in search results for a short window. For most RAG workloads this is fine — but if your agent writes a document and immediately searches for it in the same flow, it may miss the write. Plan for this.
Exact-match filters only. Inline filtering on non-vector attributes supports equality conditions only. No BETWEEN, no BEGINS_WITH. If your query logic depends on range filters, you still need a post-processing step.
100 result ceiling. TopK is capped at 100. For most retrieval workloads that is sufficient. For some ranking pipelines it is a real constraint.
Who Benefits Most #
The strongest case for DynamoDB native vector search is when your operational data and your retrieval targets are the same records. AI agent memory — store document chunks and embeddings together, retrieve context without leaving DynamoDB — is a natural fit. So are semantic product search in e-commerce, recommendation engines using user behavior vectors, and incident copilots that surface similar past events in real time.
The use cases where a dedicated vector store still wins are cost-sensitive archive scenarios. S3 Vectors offers up to 90% cheaper storage at the cost of higher latency — 238 to 501 ms versus DynamoDB’s 165 to 303 ms in published benchmarks — which is acceptable for cold RAG over millions of document chunks that are not updated frequently.
The Bigger Signal #
AWS is running the same playbook it used with full-text search and JSON document storage: absorb the specialized capability into a core product, commoditize the basic case, and force standalone vendors to compete on depth rather than existence. Futurum’s 1H 2026 survey found that 33.4% of data professionals already prefer in-database vector engines over standalone solutions. That preference will accelerate as integration friction drops further.
Pinecone and Weaviate are not going away. But the bar for justifying a separate vector database just got meaningfully higher for teams on DynamoDB. If your workload fits within the constraints — on-demand billing, eventual consistency tolerance, exact-match filters sufficient — the simpler stack is now the correct default.
Getting Started #
Update boto3 to 1.43.64 or later. Read the AWS technical walkthrough for end-to-end index creation and search setup. The official DynamoDB vector search documentation covers current quota limits, billing, and region availability. The GA announcement post includes a console walkthrough for your first vector index.