AWS Just Made DynamoDB a Vector Database

For two years, the standard answer to "how do I add semantic search to my DynamoDB app" was a second database. You'd stream table changes into OpenSearch through a zero-ETL pipeline, or replicate embeddings into Pinecone, and then spend the rest of the project keeping two systems consistent. On August 5, AWS deleted that architecture: Amazon DynamoDB now supports native vector search, generally available in every commercial region plus GovCloud.

The mechanics are deliberately boring, which is the point. You create a vector index on a table attribute, write embeddings as a list of floats with an ordinary PutItem, and query with a new SearchVectors API that takes a query vector, a result count (up to 100), and optional filter conditions. Indexes support up to 4,096 dimensions and cosine, Euclidean, and dot-product distance. AWS claims single-digit-millisecond latency at 99%+ recall, at "any scale, even trillions of vectors." Embeddings come from wherever you like — Amazon Bedrock Titan, Cohere, OpenAI — because DynamoDB just stores and searches the floats.

The dual-database tax was the product gap

It's worth being clear about what this actually replaces, because "you no longer need a vector database" undersells it. The painful part of the old pattern was never running OpenSearch or paying Pinecone. It was the synchronization pipeline: a DynamoDB stream, a Lambda, retry logic, backfill jobs, and a permanent low-grade anxiety about whether the search index reflects the table. Every RAG or recommendation feature bolted onto an operational database inherited that pipeline, and it failed in all the usual eventually-consistent ways — deleted records still surfacing in search, new records missing for minutes.

Putting the ANN index inside the database that owns the data kills that whole class of bugs. This is the same consolidation story that played out in relational land when pgvector made Postgres a good-enough vector store and a big chunk of the dedicated-vector-DB market evaporated for anyone already on Postgres. DynamoDB is arguably the last major operational database to get there — MongoDB Atlas, Cosmos DB, Redis, and Elasticsearch all shipped native vector search years ago, and even ScyllaDB beat AWS to it on DynamoDB's own API this past May. This launch is late, but it's the one that matters for the enormous installed base of single-table-design AWS shops.

Where it fits in AWS's five vector stores

AWS now sells vector search in at least five places, and the lineup finally reads as a coherent tiering story rather than org-chart sprawl. S3 Vectors is the cold, cheap tier — subsecond queries over massive archives. Amazon OpenSearch Service remains the right call when you need hybrid retrieval: BM25 plus vectors, aggregations, faceting, real search-engine features. MemoryDB is the ultra-low-latency in-memory niche. Aurora and RDS cover the pgvector crowd. DynamoDB's slot is hot, operational, high-concurrency similarity search sitting next to live application state — which happens to be exactly the shape of agent memory. Session history keyed by user, semantic recall over past interactions, and the agent's working state all land in one table, with the vector index's optional partition key giving you per-tenant isolation for free — something dedicated vector stores make you model with namespaces.

That agentic-workload framing isn't marketing garnish. If you're building agents on AWS today, the practical alternative was OpenSearch Serverless via Bedrock Knowledge Bases, which carries a meaningful baseline cost and a separate service to reason about. A DynamoDB table your agent already reads and writes is a materially simpler system.

The fine print you'll actually hit

Three limitations deserve more attention than the launch coverage gave them. First, filter conditions are exact-match only — no BETWEEN, no BEGINS_WITH. "Find similar documents from the last 30 days" doesn't express natively; you'll bucket timestamps into discrete values or over-fetch and filter client-side. pgvector and OpenSearch both handle range predicates, and for a lot of retrieval workloads metadata filtering is half the query. Community threads have also poked at whether filtering happens before or after the similarity computation, which determines whether a selective filter tanks your effective recall. AWS's docs call it "inline filtering"; benchmark it against your own filter selectivity before trusting it.

Second, vector search requires on-demand capacity mode. If you're running provisioned throughput with reserved capacity to keep a high-traffic table cheap, adding vectors means rethinking that.

Third, pricing is per-gigabyte across three new dimensions: $0.52/GB written to the index, $0.002/GB processed at search time, and GB-month storage, with a 1 KB minimum per operation. The absolute numbers are friendly — a million 1,024-dimension float32 embeddings is roughly 4 GB, about two dollars in write fees — but "data processed during searches" is a usage-shaped bill, not a request-shaped one, and it'll punish fat vectors with All-attribute projections. Keep dimensions modest and projections lean.

Genuine shift, with a defined blast radius

My read: this is real consolidation, not a checkbox feature. The engineering claims are consistent with DynamoDB's track record, and GA-everywhere-on-day-one — GovCloud included — signals AWS ran this against serious internal workloads before shipping. If you're on DynamoDB and maintaining a sync pipeline to a vector store purely for ANN lookup, migrating is close to a no-brainer: same table, one new index, one new API call, one fewer distributed system.

The blast radius is specific, though. Pinecone and friends lose the AWS-native customer who needed plain similarity search, but they keep everyone who needs range filters, hybrid retrieval, or multi-cloud portability. OpenSearch keeps the real search workloads. What dies is the middle: the glue-code architecture where a queue and a Lambda existed only to copy embeddings from the database that owned them to the database that could search them. That pattern deserved to die, and every operational database that hasn't absorbed vector search yet should read this launch as its deadline.