DynamoDB Now Does Vector Search, So Your Sync Pipeline Needs a Business Case

AWS has added a `SearchVectors` API to DynamoDB, letting developers store embeddings alongside application data and run approximate nearest-neighbour queries against them without standing up a separate vector database ^[1]. Until now, applications on DynamoDB that wanted vector search had to copy data into a second store and keep the two synchronised, which added architectural complexity and data transfer ^[2]; that pipeline is no longer a requirement, which means it now needs a justification.

The mechanics are unremarkable in a good way. Vector search uses a new index type built on embeddings stored in table attributes ^[3]. You pick your own embedding model, including Amazon Bedrock Titan Text Embeddings, Cohere Embed or OpenAI text embedding models, create an index with the dimensions and distance function you want, and query it through the new API ^[4]. Esra Kayabali, principal solutions architect at AWS, says the feature supports up to 4096 dimensions, Euclidean, Cosine and Dot product distance functions, and inline filtering, and that vector indexes have no storage limits and scale horizontally as data grows ^[5][6]. Jeff Barr, AWS VP and chief evangelist, wrote on LinkedIn that it scales to trillions of vectors while holding single-digit millisecond latency ^[7]. That is a vendor number on a launch, not a benchmark you ran.

The cost model is where the decision actually gets made. A vector index is billed on three dimensions on top of the standard DynamoDB charges for the table holding the items: data written into the index, data processed when you search, and data stored, all metered per byte and billed per GB ^[8]. That is four separate meters attached to one logical retrieval path ^[9]. AWS solutions architects Leonid Koren and Mo Kamioner list the main cost levers as lower dimensions, minimal index projections, excluding embeddings from query results, and selective partitioning ^[10]. The dev.to Devsignal newsletter, which called the launch a collapse of a common two-database architecture, still advises running the math before assuming it beats your current setup ^[11][12]. One commenter on the InfoQ coverage, coinclick, argued S3 offers limitless scale with consistent if unimpressive latency, and that DynamoDB will probably be a lot more expensive ^[13]. Some practitioners were blunter about the timing, saying AWS is too late to the party given how many databases shipped vector support over the past couple of years ^[14].

Migration is not free either. Setup means choosing an embedding model, configuring the index with dimensions and a distance function, and rewriting retrieval queries to use `SearchVectors` ^[15]. And at least one behaviour is still unclear to the community: developers have asked whether DynamoDB applies attribute filters before or after the vector search, which changes both recall and what you pay for search processing ^[16].

Watch three things. First, whether filter ordering gets documented, because that determines whether inline filtering is a cost saver or a post-hoc trim. Second, ExtendDB: the team plans to ship vector search through the DynamoDB-compatible adapter for local development and self-managed deployments ^[17], which is what makes this testable off the bill. Third, your own numbers. Vector indexes are available in all regions where DynamoDB is available, on Standard and Standard-IA table classes ^[18], and the sensible sequence is a proof of concept on a non-critical workload to validate cost and latency before moving production retrieval ^[19].