AWS Adds Native Vector Search to DynamoDB via SearchVectors API
In this article
Amazon DynamoDB now supports native vector search, letting developers store embeddings directly in table attributes and execute approximate nearest-neighbor (ANN) queries through a new SearchVectors API — no separate vector database required. For teams running a DynamoDB table alongside a dedicated vector store such as OpenSearch or Pinecone, that means eliminating the synchronization pipeline that keeps the two systems consistent, a source of both latency and operational overhead that has long been a tax on RAG and semantic search architectures.
How the Index Works
Vector search is implemented as a new DynamoDB index type, distinct from GSIs and LSIs. Developers attach a vector index to an existing table attribute holding the embedding, specifying the number of dimensions (up to 4,096) and a distance function. All three distance functions common in ANN workloads are supported: Euclidean, Cosine, and Dot product. The index has no storage limit and scales horizontally as the underlying table grows. Queries support inline attribute filters, allowing narrowing of the candidate set without a post-query application-side filter pass.
Any embedding model can supply the vectors. AWS documentation calls out Amazon Bedrock Titan Text Embeddings and Cohere Embed as options alongside OpenAI text embedding models, making the feature model-agnostic at the storage layer. A reference Python application by Leonid Koren, principal NoSQL specialist solutions architect at AWS, and Mo Kamioner, senior DynamoDB solutions architect at AWS, demonstrates using Bedrock embeddings with DynamoDB to retrieve research papers by semantic meaning rather than keyword overlap.
Cost Structure
Billing adds three meters on top of standard DynamoDB table charges, all denominated per byte and billed per GB:
- Data written into the vector index
- Data processed during each search
- Data stored in the index
Koren and Kamioner identify four techniques to control those meters: using lower-dimensional vectors, projecting only the attributes needed into the index, excluding the embedding attribute from query results, and selective partitioning to reduce data scanned per query. The per-byte billing model means dimension count has a direct, linear cost consequence.
Jeff Barr, VP and chief evangelist at AWS, noted that the feature supports trillions of vectors while maintaining single-digit millisecond latency. Community discussion flagged S3 Vector Buckets as a cheaper but higher-latency alternative, with one commenter observing that S3 offers consistent latency even if that latency isn't great, while DynamoDB will generally scale with very low latency but will likely be more expensive.
Architecture Trade-offs vs. Dedicated Vector Stores
| Dimension | DynamoDB Native Vector Search | Separate Vector DB (e.g., OpenSearch, Pinecone) |
|---|---|---|
| Data synchronization pipeline | Eliminated — vectors co-located with app data | Required; adds operational complexity and potential lag |
| Max vector dimensions | 4,096 | Varies by product |
| Distance functions | Euclidean, Cosine, Dot product | Typically the same three, plus additional quantization options |
| Inline attribute filtering | Supported | Supported in most managed products |
| Infrastructure management | Fully serverless | Varies; many require cluster sizing decisions |
| Storage limit | No stated limit; horizontal scale | Varies; often node-count dependent |
| Cost model | Per-byte on writes, searches, and storage, plus base table charges | Typically per-vector or per-node pricing |
| Local development support | Planned via ExtendDB DynamoDB-compatible adapter | Generally available today via local containers |
Local development is a current gap: the ExtendDB adapter will eventually carry the feature for local and self-managed deployments, but it has not yet shipped. Teams relying on local DynamoDB emulation for integration testing will need to account for this before migrating.
Availability
Vector indexes are live in all regions where DynamoDB is currently available and work with both the Standard and Standard-IA table classes. The SearchVectors API integrates with the existing DynamoDB SDK surface, including DynamoDB Streams, conditional writes, and transaction semantics.
The launch fits a broader pattern in which agentic applications are pushing data infrastructure to absorb retrieval responsibilities directly, rather than delegating them to bolt-on systems. For teams already paying the operational cost of a split DynamoDB and vector store architecture, collapsing the vector tier into the same table removes a meaningful category of infrastructure risk — the question is whether the per-byte billing model pencils out against current vector store spend at production embedding volumes.