# DynamoDB Vector Search Goes GA: What AWS Devs Must Know
> Source:
> Published: 2026-08-15 06:15:11+00:00
AWS launched native vector search for Amazon DynamoDB on August 5, 2026 — straight to general availability, no public preview. The feature, built around a new `SearchVectors`
API, lets developers store vector embeddings directly in DynamoDB and run approximate nearest neighbor queries against them. For AWS teams building RAG pipelines, semantic search, or AI agent memory, this ends the most common architectural headache in the space: maintaining a separate vector database alongside DynamoDB and keeping them in sync.
## One Table, No Sync Pipeline
The core value here is not the query API — it is what disappears when you use it. Today, most AWS teams running DynamoDB for operational data have a painful second act: replicate that data to Pinecone, OpenSearch, or a pgvector instance; write and maintain sync pipelines; pay for two services; debug the subtle failures when something drifts out of sync. DynamoDB vector search eliminates that entire layer.
Vectors are stored as standard `List`
attributes in the same table as your operational data. A single `SearchVectors`
call retrieves similar items and their associated operational attributes in one round trip. According to the [official AWS launch post](https://aws.amazon.com/blogs/aws/amazon-dynamodb-now-supports-real-time-vector-search-at-any-scale/), the feature scales to trillions of vectors with single-digit millisecond latency at 99%+ recall. For e-commerce, agent memory, fraud detection, and content recommendation workloads already living in DynamoDB, the architecture just got simpler.
Related:[AWS AgentCore Is Here: What to Do Before Classic Locks You Out]
## DynamoDB Vector Search Works — With These Limits
Read the [official documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/VectorSearch.html) before planning a migration. Two constraints matter most. First, vector indexes require on-demand capacity mode — if your table runs on provisioned throughput (common for cost-sensitive production workloads), you cannot use this feature without switching billing models. Second, inline filters support equality operators only: you can filter by `category = 'electronics'`
but not by `price BETWEEN 10 AND 100`
. Range conditions are not yet supported.
Additional hard limits: maximum 100 results per `SearchVectors`
call, up to 4,096 dimensions per vector, and a cap of 5 vector indexes per table. Pagination is not available for vector search. The API also excludes the vector attribute from results by default — a deliberate cost-control choice, since returning large embeddings inflates processed bytes. Request it explicitly in your `ProjectionExpression`
only when you actually need it.
A minimal Boto3 call looks like this (Boto3 1.43.64 or later required):
```
results = dynamodb.search_vectors(
TableName='Products',
IndexName='EmbeddingIndex',
QueryVector=[0.1, 0.2, ...], # your query embedding
TopK=10,
SearchConditionExpression='category = :cat',
ExpressionAttributeValues={':cat': {'S': 'electronics'}}
)
```
## Pick the Wrong Distance Function and Results Are Silently Wrong
Distance function selection is permanent — you cannot change it after the vector index is created. Getting it wrong means your search runs, returns results that look reasonable, and nobody notices the semantic errors. The choice is straightforward once you know the rules: use **COSINE** for text embeddings from models like Amazon Titan or Cohere Embed (lower score means more similar, 0 is identical). Use **DOT_PRODUCT** when your embedding model’s documentation recommends it, or when you want vector magnitude to influence ranking — for example, scaling product embeddings by popularity score so popular items rank higher. Use **EUCLIDEAN** for image or audio embeddings where absolute spatial distance matters, like near-duplicate detection.
One gotcha that catches developers off guard: DOT_PRODUCT scores can be negative. A vector pointing in the opposite direction scores below zero. Do not assume results are always non-negative when you sort or apply thresholds. When uncertain, COSINE is the safe default for most LLM-driven applications.
## Should You Migrate to DynamoDB Vector Search?
DynamoDB vector search is the right choice if you are already on DynamoDB, your vector queries require only equality filtering, on-demand capacity mode is acceptable, and you need vectors co-located with operational data for atomic reads. However, it is not a universal replacement for dedicated vector databases. If you need range filters, pagination beyond 100 results, or advanced hybrid search, Pinecone or pgvector remain stronger options. AWS’s own [S3 Vectors service](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-dynamodb-vector-search/) is worth evaluating for archival or batch vector workloads — storage runs up to 90% cheaper, though median query latency is higher.
The vendor lock-in angle is also worth considering. Building your vector layer inside DynamoDB deepens your AWS dependency. For some teams, that is an acceptable trade for operational simplicity. For others, it is not. Know which camp you are in before you migrate. For a sharper look at what lock-in actually costs, see [Cloud Vendor Lock-In Erased Nine PBS’s 70-Year Archive](https://byteiota.com/cloud-vendor-lock-in-erased-nine-pbss-70-year-archive/).
## Key Takeaways
- DynamoDB vector search went GA on August 5, 2026, in all commercial AWS regions — no public preview, straight to production.
- The primary benefit is eliminating separate vector database infrastructure and the sync pipelines that go with it.
- Hard constraints: on-demand capacity mode required, equality-only inline filters, TopK capped at 100 results.
- Distance function is permanent at index creation — use COSINE for text embeddings unless your model documentation says otherwise.
- Evaluate S3 Vectors for archival workloads; stay on Pinecone or pgvector when range filtering is a requirement.