AWS Adds Vector Search to DynamoDB, Eliminating Sync Pipelines

AWS made vector search generally available in DynamoDB on August 5, 2026 — single-digit millisecond latency at 99%+ recall, scales to trillions of vectors. Teams on DynamoDB for transactional workloads can now store embeddings in the same table, build a vector index on any attribute, and run approximate nearest-neighbor queries through the new SearchVectors API. No separate vector database. No sync pipeline.

A developer generates embeddings with any model — Bedrock Titan Text Embeddings V2, Cohere Embed, OpenAI — and stores them as floats on the DynamoDB item. Then creates a vector index specifying the attribute name, dimension count, and distance function. DynamoDB supports up to 4,096 dimensions and three distance functions: Euclidean, Cosine, Dot product. SearchVectors returns up to 100 results ranked by similarity score, with item data returned inline. SDK requirement: boto3/botocore ≥ 1.43.64.

The elimination of the sync pipeline changes platform economics. Until now, a DynamoDB application needing semantic search had to copy data into a separate vector store — Pinecone, Weaviate, OpenSearch — and run a pipeline to keep embeddings current. Two databases to monitor. Data movement costs. A failure surface between write and read paths. AWS architects Leonid Koren and Mo Kamioner enumerate the cost: sync complexity, an extra network round-trip to fetch item data after the vector lookup, the cost of two managed services, and two separate failure modes.

Billing sits on top of standard DynamoDB charges: writes into the vector index ($/GB), data processed per search ($/GB), and storage ($/GB). AWS recommends reducing costs by using lower-dimensional models, projecting only necessary attributes into the index, excluding embeddings from query results, and partitioning the index selectively. The precise per-GB rates live on the DynamoDB pricing page. Teams should benchmark against current Pinecone or OpenSearch spend. Consolidation does not always save money.

Filter conditions at query time are limited to exact-match predicates on non-vector attributes — not range queries, not inequality operators. Teams that need "return results where price < $100" alongside vector similarity will not get that from a single SearchVectors call. The workaround is filtering in application code post-retrieval, which increases the result set you pay to process. Specialist stores handle this more flexibly.

S3 Vector Buckets cost less per query and scale without bound. DynamoDB's edge is real-time retrieval latency. For agentic memory that needs sub-10ms lookup, DynamoDB is the right call. For batch nearest-neighbor workflows or offline retrieval where a 100ms tail is acceptable, S3 may be cheaper at scale.

AWS already ships vector search in Aurora, RDS, MemoryDB, DocumentDB, Neptune Analytics, and OpenSearch. DynamoDB completes the core transactional tier. A Futurum survey of data professionals in the first half of 2026 found 33.4% prefer an in-database engine as their long-term vector embedding strategy — the largest single bloc. Architects choosing between a dedicated vector store and a consolidated approach have one fewer reason to run a separate service if DynamoDB is already in the stack.