I've wanted a searchable index on DynamoDB for a long time. Not a keyword index bolted on through OpenSearch and a streams pipeline, but something native, something that didn't require standing up and syncing a second database just to answer "find me something like this."
AWS just shipped it, and it's not the keyword search I originally wanted. It's vector search, and honestly, that's a better outcome. Vector search doesn't match strings, it matches meaning. "Lightweight running shoes for summer" doesn't need to contain any of those exact words in the product description to be the best result. That's a different kind of useful than begins_with, and in a lot of cases, more useful.
Why This Matters Beyond Search
The obvious use case is product or document search where users type natural language instead of exact keywords. But the bigger deal is everything downstream of "AI application" that needs a memory:
- Retrieval augmented generation (RAG) — pull relevant context into a prompt based on semantic similarity, not exact keyword hits
- Agentic memory — let an agent recall prior interactions or facts that are conceptually related, not just textually identical
- Recommendation engines — "users who engaged with similar content" without a separate ML feature store
- Anomaly detection — flag data points that are semantically distant from the norm
Every one of these previously meant standing up a dedicated vector database (Pinecone, OpenSearch with k-NN, pgvector) and building a sync pipeline to keep it consistent with your source of truth. If your operational data already lives in DynamoDB, that's real operational overhead: extra infrastructure, extra cost, and a consistency lag between your table and your index. Now the vectors live next to the data they describe, in the same table, updated with the same PutItem call.
How It Actually Works
Embeddings are stored as a List of Number elements, same as any other DynamoDB attribute. Adding vector search to an existing table takes four steps:
- Generate an embedding for the text you want searchable (Amazon Bedrock Titan Text Embeddings, Cohere Embed, or any embedding model you're already using)
- Store it as a new attribute on the item with a normal
UpdateItemcall - Create a vector index on that attribute, specifying dimensions, distance function, and any non-vector attributes you want to filter on
- Query it with the new
SearchVectorsAPI
UpdateItem
Table: ProductCatalog
Key: { productId: "SKU-1042" }
Update: SET descriptionEmbedding = [0.0123, -0.0456, ...]
The vector index sits alongside your table like a GSI does conceptually, but it's a different index type built for similarity search rather than exact or range lookups. You choose a distance function based on what you're comparing:
- Cosine — angle between vectors, ignores magnitude. Good default for text embedding similarity.
- Euclidean — straight-line distance, magnitude matters. Useful when clustering by a numeric signal.
- Dot product — direction and magnitude both matter. Common in recommendation systems weighting interest and frequency together.
Match the distance function to whatever your embedding model was trained with, or accuracy suffers.
The Partition Key Still Matters
This is the detail that made me nod along rather than just skim: vector indexes still take a partition key, and it's still doing the same job it always does in DynamoDB. Each SearchVectors call is scoped to a single partition key value, so a multi-tenant product catalog can search within one marketplace's inventory instead of scanning across all of them. Skip it if your dataset is small; use it if you're operating at any real scale, exactly the same advice as every other DynamoDB index.
You can also add inline filters — exact-match conditions on non-vector attributes (like category = footwear) evaluated alongside the similarity search. No BETWEEN or BEGINS_WITH on filters yet, just equality, but combined with the partition key it's enough to scope most real queries.
This Is Also Tenant Isolation
Here's the detail that matters most if you're running multi-tenant SaaS on DynamoDB: each SearchVectors call is scoped to exactly one partition key value. Not "filtered to," scoped to. The partition key on a vector index is a separate attribute you define when creating the index, it doesn't have to match your base table's PK, but the natural move is to set it to the same tenant identifier you're already using, like TENANT#acme.
That means semantic search gets the same hard isolation guarantee as a normal query. A query against TENANT#acme cannot return a result from TENANT#other, because the search never looks outside that partition. You're not filtering tenant data out after the fact in application code, where a bug could leak a result across tenants. The index structure itself makes it impossible.
The partition key on a vector index is optional. If you skip it, SearchVectors scans the entire index regardless of tenant, which is the wrong default for any multi-tenant table. If you've already adopted tenant-prefixed partition keys elsewhere in your schema, carrying that same convention into your vector index costs nothing and buys you the same isolation you already rely on everywhere else.
SearchVectors
Index: ProductDescriptionIndex
PartitionKey: "US"
QueryVector: [0.0089, -0.0234, ...]
TopK: 5
Filter: { category: "footwear" }
That returns the five most semantically similar footwear products in the US marketplace, ranked by similarity score, with your normal item attributes (name, price) included in the response. No second round trip to hydrate results from the source table.
About That Cost
My first reaction reading the announcement was that this feels expensive, and digging into the pricing page, that instinct holds up. Vector search bills on three dimensions on top of your normal table charges: vector writes (per GB written into the index), vector search (per GB processed to answer a query, not per query), and storage (per GB-month, like table storage).
Vector search has more in common with a table Scan. AWS says directly that "the data processed grows with the size of the index, because the search scans across more data to find the nearest matches." AWS's own worked example puts this in dollars: one million items with 3 KB vectors, 10 writes/sec and 10 searches/sec. The base table runs about $65.75/month; vector search adds another $55.54/month on top, split mostly between vector writes ($51.42) and search ($3.17). That's comparable to the base table cost, not a rounding error.
The partition key is your main lever here, and it works differently than on a base table. A vector index's partition key is optional and chosen at index creation, not required like a table's. Define one, and every search is priced against just that slice of the index. Skip it, and every search scans (and pays for) the whole thing. For anything beyond a toy dataset, that's a cost control as much as an access pattern decision.
A few smaller levers: dimension count drives cost linearly, so don't default to a 4096-dimension model when 256 or 512 is accurate enough. Project only the attributes you need back rather than ALL. And the vector attribute itself isn't returned by default, which quietly saves you from paying to ship a few KB of floats back on every result.
An Unadvertised Use Case: Geospatial Nearest-Neighbor
AWS's pitch for vector search is entirely about embeddings and AI, but nothing about the feature restricts vectors to high dimensions. Set Dimensions to 3 and pick EUCLIDEAN as the distance function, and you're no longer doing semantic similarity. You're doing real geometric distance.
This is a natural fit for "find the K nearest X to this point" queries: nearest store locations, nearest sensors, nearest players on a map. I've built geospatial indexing into FluentDynamoDB using three different standards (Geohash, S2, and H3), and each has a real tradeoff. Geohash is a range search on a sort key, so precision and boundary artifacts at cell edges are a known headache. S2 and H3 avoid the boundary problem with hierarchical cells, but a radius search means pulling every cell that intersects your search radius and filtering client-side, so you're always over-fetching relative to what you actually need.
Vector search skips both problems, if you set it up right. The naive approach of feeding raw latitude/longitude in as two dimensions breaks down over distance, because a degree of longitude shrinks as you move toward the poles, distorting flat Euclidean distance. The fix is to convert lat/lon into 3D Cartesian coordinates instead: treat the earth as a sphere and represent every point as an (x, y, z) position in space, the same trick used in GIS and aerospace systems (the technical name is ECEF, short for "Earth-Centered, Earth-Fixed"). Euclidean distance between two points in that 3D space corresponds to a straight line cutting through the earth between them (the "chord distance"), and that chord distance always ranks points in the same order as their true distance along the earth's curved surface. So even though the raw number isn't kilometers, ranking by it gives you the correct nearest-neighbor order, no geohash cells, no radius over-fetch, no boundary distortion.
CreateVectorIndex
Dimensions: 3
DistanceFunction: EUCLIDEAN
VectorAttribute: locationEcef # [x, y, z] position on a sphere representing the earth
SearchVectors
QueryVector: [x, y, z] # your search point, converted the same way
TopK: 10 # return the 10 closest matches
Two honest caveats before you reach for this. First, SearchVectors uses approximate nearest neighbor search (ANN) rather than checking every item exactly. It trades a small amount of accuracy for speed at scale, AWS claims 99%+ recall, which is fine for "nearest coffee shop" and probably not what you want if you need guaranteed exactness. Second, the API returns a fixed count of closest matches (TopK) rather than everything within a radius. There's no "everything within 5 km" query, you either request a generous TopK and filter afterward, or accept the estimate. The partition key still earns its keep here too: use a coarse region (country, geohash prefix, whatever grouping makes sense) as the partition, then get nearest-neighbor ranking within it.
I haven't tried this myself yet, but it's on my list.
Where I'd Actually Use This
For teams already on DynamoDB, the calculus for "do we need a search cluster" just changed. If your search needs are semantic similarity plus a bit of filtering, vector search on DynamoDB removes an entire piece of infrastructure and the pipeline that kept it in sync. If you need full-text search with relevance scoring across arbitrary fields, ranking, fuzzy matching, and faceted filtering, OpenSearch is still the right tool. Vector search isn't a replacement for that; it's a different capability that happens to now live where your data already does.
I'm also looking at what this means for FluentDynamoDB.
A Confirmation on the Fate of DynamoDB Local
One more thing worth flagging, buried in the comments on the announcement. Someone asked the obvious question: when will DynamoDB Local support vector search? The answer, from AWS's Deepthi Mohan:
"We will ship vector search through ExtendDB. The DynamoDB team maintains ExtendDB as an open source project under Apache 2.0, and it can be used for local development and self-managed deployments."
Vector search through ExtendDB only. That's a clear signal about where the team's local development investment is going.
This confirms what I called out when ExtendDB shipped in June: AWS is moving away from DynamoDB Local as the reference local implementation. Vector search is the first real feature where that shift shows up in public. If you're setting up integration tests for it, ExtendDB isn't just the better option, it's the only one AWS is building.
AWS announcement: Amazon DynamoDB now supports real-time vector search at any scale
