DynamoDB vector search GA: one less database to run

AWS made DynamoDB vector search generally available: you can store embeddings in the same table as your operational data and run similarity search against them, with no separate vector database and no sync pipeline. For most small teams building retrieval into an app, this deletes an entire moving part — the one that was quietly the most likely to be stale.

What actually happened

Per the AWS announcement on Aug 5 and the AWS News Blog writeup, DynamoDB adds a new index type for vectors stored as lists of floats. You generate embeddings wherever you like — Bedrock, Cohere, OpenAI — create a vector index specifying dimensions, distance function, and optional filter attributes, then query with a new SearchVectors API that takes a query vector and returns ranked results.

The numbers AWS publishes: single-digit millisecond latency at 99%+ recall, up to 4,096 dimensions, and Euclidean, cosine, or dot product distance. No storage limit on indexes; AWS says it scales horizontally to trillions of vectors. Pricing is DynamoDB's normal pay-per-request model — no separate vector database license. Generally available in all commercial AWS Regions plus GovCloud (US).

The catch is in the filtering. Inline filters on non-vector attributes are exact-match only. If your retrieval needs a range (price under $50, orders in the last 90 days, stock greater than zero) applied during the search, you're either restructuring those into exact-match attributes or filtering after the fact and hoping enough results survive.

Why native vector search matters for your business

The strongest argument here isn't latency. It's that the sync pipeline goes away.

Stale embeddings are the most common RAG bug we see. The classic architecture writes a product to Postgres or DynamoDB, then a job pushes an embedding to Pinecone or OpenSearch. That job fails silently, and three weeks later your assistant is confidently describing a discontinued SKU. Vectors living in the same item as the record can't drift from it. This is the same lesson as agents failing on data, not the model — the retrieval layer breaks before the LLM does.

One fewer vendor, one fewer bill, one fewer thing to patch. For a team running a catalog with a few hundred thousand items, a dedicated vector store was always overkill infrastructure you still had to operate. Consolidating it into a database you already run is a real reduction in surface area.

Model the filters before you commit. Exact-match-only filtering is the design constraint that decides whether this fits. Denormalize your ranges into buckets you can match exactly (price_band, age_bucket), decide that up front, and you'll be fine. Discover it after you've migrated and you'll be rewriting your access patterns — which is the usual DynamoDB tax, now applied to retrieval.

And the obvious tradeoff: this makes DynamoDB harder to leave. If portability is a live concern for you, weigh that against the operational win honestly rather than pretending the lock-in isn't real.

Sources: AWS What's New, AWS News Blog.