DynamoDB Adds Native Vector Search, Making Dedicated Vector Databases Obsolete for Operational Workloads

July 30, 2026, AWS, AWS Summit New York: DynamoDB has made the largest architectural leap in its history. Amazon’s serverless NoSQL database now includes native vector search — a capability that previously required a dedicated vector database (Pinecone, Weaviate, OpenSearch) synchronized with the operational database through an ETL pipeline that was never quite reliable.

The announcement, made at the AWS Summit New York 2026 by Swami Sivasubramanian, VP of Agentic AI at AWS, reshapes architectures for RAG (Retrieval-Augmented Generation), recommendation engines, and semantic search. All with zero servers to provision, zero maintenance windows, and the same pay-per-request pricing as the rest of DynamoDB.

The end of the « operational DB + vector DB » pattern

Since 2023, the standard architecture for adding semantic search to an application looked like this:

Application → DynamoDB (operational data)
            → ETL Pipeline (Lambda / Kafka)
            → Vector Database (Pinecone, Weaviate, OpenSearch)

This pattern imposed three costs that teams know all too well:

• Synchronization cost: every update in DynamoDB must be replicated to the vector database. The ETL pipeline is a source of bugs, latency, and data divergence.
• Financial cost: a dedicated vector database charges by stored vector count, often with a monthly minimum. For a 50 million product catalog, the Pinecone bill can exceed $2,500/month before the first query.
• Cognitive cost: two databases, two SDKs, two consistency models, two monitoring dashboards. Operational simplicity does not exist here.

With native vector search, DynamoDB stores embeddings directly in table items as a List attribute of floats. One table, one API call, one bill.

What DynamoDB Vector Search does — and does not — do

The feature is built on a new index type: the Vector Index. Creating one takes a handful of parameters:

aws dynamodb create-vector-index \
    --table-name ProductCatalog \
    --index-name ProductDescriptionIndex \
    --vector-attribute-name descriptionEmbedding \
    --dimensions 1536 \
    --distance-function cosine \
    --partition-key marketplace \
    --inline-filter-attributes category

Key capabilities:

• Up to 4,096 dimensions per vector — compatible with OpenAI text-embedding-3-large (3,072 dims), Cohere Embed v4 (4,096), and Amazon Titan Embeddings G1 (1,536).
• Three distance functions: Cosine (semantic similarity), Euclidean (geometric distance), Dot Product (ranking relevance).
• Inline filtering: restrict searches to a partition and exact-match attributes (e.g., « find similar shoes, but only in the footwear category of the US marketplace »).
• < 10 ms P99 latency on indexes of several billion vectors, thanks to DynamoDB native partitioning.
• No storage limits: the index scales horizontally with the table.

What DynamoDB Vector Search does not do:

• No range filtering (BETWEEN, BEGINS_WITH) on inline filter attributes — exact equality only.
• No hybrid search (vector + full-text) — OpenSearch remains necessary for that use case.
• No built-in LLM re-ranking — the similarity score is raw, without an additional semantic relevance layer.

For use cases where exact-match filtering suffices and full-text search is not required, DynamoDB now covers the entire need.

Who should migrate — and who should not

The migration decision depends on the ratio between your vector data and your operational data.

Migrate if your operational data already lives in DynamoDB and you maintain a synchronization pipeline to an external vector database. This is the most common scenario in RAG architectures for product catalogs, internal documentation, or customer knowledge bases. Removing the pipeline reduces indexing latency from several seconds to < 100 ms and eliminates divergence risk.

Do not migrate if you need hybrid vector + full-text search, complex filtering (range, nested boolean), or if your vector data volume far exceeds your operational data. OpenSearch and Pinecone remain superior for pure semantic search with reranking.

Borderline case: if you use Pinecone serverless for its simplicity and your embeddings already originate from DynamoDB data, the migration cost is near zero — one UpdateItem to add the embedding attribute, one CreateVectorIndex, and you delete the pipeline.

Cost: what really changes

DynamoDB Vector Search pricing follows the same model as the rest of the service. No fixed fees, no instances to provision:

For a real-world case — 50 million products with 1,536-dimension embeddings (Titan Embeddings G1, ~6 KB per vector):

• Before: DynamoDB ($300/month storage) + Pinecone p1.x2 ($2,500/month) + Lambda ETL (~$150/month) = ~$2,950/month
• After: DynamoDB alone (~$300/month storage + ~$50/month writes + ~$100/month reads) = ~$450/month

An 85% reduction. The number varies with query volume, but the order of magnitude holds across all use cases where the ETL pipeline was the primary cost driver.

Verdict

DynamoDB Vector Search is not a Pinecone or Weaviate killer for all use cases — but it is for one use case in particular, and it happens to be the most common: « I have data in DynamoDB, I want to run semantic search on it without adding a second database. »

If that describes your situation, migration is a financial and operational no-brainer. Delete the sync pipeline, add the vector index, and save 80–90% on your monthly semantic search bill. If you need hybrid search or complex filtering, keep OpenSearch — but feed it from the same DynamoDB Stream rather than maintaining two redundant datasets.

The 2027 RAG architecture will have one fewer database. AWS just removed it from the diagram.

References

• AWS News Blog, « Amazon DynamoDB now supports real-time vector search at any scale », July 30, 2026
• AWS Summit New York 2026, Keynote by Swami Sivasubramanian, July 30, 2026
• Amazon DynamoDB Developer Guide, « Vector Search for DynamoDB », accessed August 6, 2026