Updated 16 Aug 2026: Adds AWS's now-published vector-index pricing, metering and throughput quotas, and updates builder guidance around partitioning as a direct cost and scale control.
Key details
- Vector indexes use approximate nearest-neighbour search through the `SearchVectors` API.
- In US East (N. Virginia), AWS lists vector writes at $0.52 per GB, vector search at $0.002 per GB processed and vector-index storage at $0.25 per GB-month.
- Vector pricing is separate from normal DynamoDB table read, write and storage charges.
- AWS's worked example for one million 768-dimension vectors at 10 writes/s and 10 searches/s produces $55.54/month in vector-index charges.
- The default vector-search rate is 1 GB/s per vector partition-key value; the default vector-index write rate is 10 MB/s per partition-key value.
- A vector index supports up to 4,096 dimensions and `SearchVectors` has a maximum TopK of 100.
- A table can have five vector indexes by default; AWS says that quota is adjustable through support.
- Inline filters currently support equality only, and DAX does not support `SearchVectors`.
What builders should take away
- Model vector cost from bytes processed, not just query count. A query that scans a large vector partition can cost more than one constrained to a narrow tenant or category boundary even at the same request rate.
- Use vector partition keys that line up with real query isolation boundaries such as tenant, geography or corpus. AWS explicitly ties partitioning to lower bytes scanned, better latency and horizontal throughput scaling.
- Instrument `VectorSearchRequestBytes` and `VectorWriteRequestBytes` with `ReturnConsumedCapacity` and CloudWatch before committing to the architecture; those metrics expose the direct cost drivers.
- Compare total system cost rather than only vector-index charges. DynamoDB may be attractive when it eliminates replication pipelines and an extra datastore, even if raw search pricing is not the absolute minimum.
- Keep a dedicated search system when you need complex filters, hybrid lexical search, more than 100 results per request or vector-search controls beyond DynamoDB's current scope.
What changed
Amazon DynamoDB now supports vector indexes that store and search embeddings alongside normal table items. Since BTN's initial dossier, AWS has published more detailed operational and pricing guidance: vector-index usage is billed separately for vector writes, vector searches and vector-index storage; US East (N. Virginia) pricing is $0.52 per GB written, $0.002 per GB processed by search and $0.25 per GB-month of vector-index storage. AWS also documents default per-partition-key limits of 1 GB/s for vector search and 10 MB/s for vector-index writes, alongside a 4,096-dimension maximum and TopK limit of 100.
Why it matters
The feature's appeal is architectural simplicity, but the new pricing and throughput details show exactly where that simplicity can become expensive or constraining. Search cost is tied to bytes processed, so partitioning the vector index well matters both for latency and for spend. Teams can now compare DynamoDB's native approach more concretely with a separate vector database instead of evaluating only feature fit.
Vector search now lives beside operational records
A DynamoDB vector index points at an embedding attribute in the same table that holds the application's normal data. `SearchVectors` performs approximate nearest-neighbour search and can return projected attributes with each match, allowing applications to retrieve semantic neighbours without maintaining a separate replication path into another vector store.
AWS now exposes the cost model clearly
Vector-index operations are metered separately from the base DynamoDB table. In US East (N. Virginia), AWS lists vector writes at $0.52 per GB, vector search at $0.002 per GB processed and vector-index storage at $0.25 per GB-month. Its worked example for one million 768-dimension vectors, 10 writes per second and 10 searches per second totals $55.54 per month for the vector-index portion on top of $65.75 for the underlying table. Region and workload shape still matter, so teams should model their own access pattern rather than copy the example directly.
Partition design controls both scale and spend
AWS documents a default vector-search throughput limit of 1 GB/s per vector partition-key value and a vector-index write limit of 10 MB/s per partition-key value, both adjustable through support. A search constrained to one partition key examines less data, which AWS says can lower cost, improve latency and recall, and scale throughput horizontally across key values. Poor partitioning therefore affects more than performance.
There are important limits versus dedicated search systems
DynamoDB allows up to five vector indexes per table, with a default quota that AWS says can be increased through support. Each index supports up to 4,096 dimensions, `SearchVectors` returns at most 100 nearest neighbours per request, inline filters remain equality-only, and vector indexes require on-demand capacity mode. DAX does not support `SearchVectors`.
Global tables remain useful, with asynchronous vector visibility
Vector-index definitions replicate with DynamoDB global tables and searches run against the local Region's index. AWS says replicated items are indexed asynchronously, so applications should still treat newly written vectors as eventually visible across Regions even when the underlying global-table mode provides stronger consistency for base-table reads.
Timeline
2026-08
AWS documents native DynamoDB vector indexes
AWS adds first-party documentation for vector indexes and SearchVectors, bringing ANN similarity search directly into DynamoDB.
2026-08
AWS publishes vector pricing and throughput guidance
AWS documents separate vector write, search and storage metering, worked pricing examples and per-partition-key throughput quotas.
What to watch next
- Real-world cost and latency comparisons against OpenSearch Serverless, S3 Vectors and specialist vector databases using comparable datasets and recall targets.
- Whether DynamoDB expands inline filtering beyond equality and adds hybrid lexical-plus-vector search.
- Whether AWS changes the current TopK, dimension or per-partition throughput limits.
- Whether Bedrock Knowledge Bases or other AWS agent tooling adds direct integrations with DynamoDB vector indexes.
Still unclear
- AWS's worked pricing example is illustrative rather than a benchmark; real cost depends on vector dimensions, projection size, partitioning, search rate and Region.
- AWS documentation establishes the feature mechanics and price model, but it does not show where DynamoDB vector search will outperform specialist alternatives on latency or recall.
- The best architecture still depends heavily on corpus size, query partitionability and filter requirements; removing a separate vector store is not automatically an improvement for every workload.
Sources
Direct reading behind this dossier.
Using vector indexes in DynamoDB
Amazon Web Services
primary
Primary documentation for SearchVectors, feature mechanics, limits and supported use cases.
Amazon DynamoDB Pricing
Amazon Web Services
primary
Current official pricing page with vector write, search and storage rates plus a worked RAG example for US East (N. Virginia).
Monitoring vector index capacity
Amazon Web Services
primary
Primary documentation for VectorSearchRequestBytes, VectorWriteRequestBytes and cost drivers.
Quotas in Amazon DynamoDB
Amazon Web Services
primary
Primary source for vector-index quotas including dimensions, TopK and per-partition-key throughput.
Best practices for vector indexes
Amazon Web Services
primary
Primary guidance on partitioning, dimensions, cost and search design.