Amazon DynamoDB Adds Real‑Time Vector Search at Any Scale – What You Need to Know

AWS announced the general availability of native vector search in Amazon DynamoDB. The feature adds a new index type that can be defined on any attribute containing a list of floating‑point numbers, allowing similarity queries to be executed directly against the same table that holds the application’s operational data.

Vector embeddings are stored using DynamoDB’s existing List data type; each element is a Number representing a single float from the embedding vector. Because the schema does not change, developers can enrich items such as productId, price, or timestamp with an additional attribute (e.g., descriptionEmbedding) via a standard PutItem or UpdateItem call. This eliminates the need for a separate vector database and the associated data‑movement pipelines.

When creating a vector index you must specify:

• Number of dimensions (up to 4 096).
• Distance function – Cosine, Euclidean, or Dot product. The choice should match the metric used during model training for optimal recall.
• Optional partition key to distribute vectors across partitions and enable scoped searches.
• Inline filter attributes for exact‑match filtering at query time.

Practical example – adding semantic search to a product catalog:

1. Generate text embeddings for each product description using a model such as Amazon Bedrock Titan Text Embeddings.
2. Store the embedding list in a new attribute descriptionEmbedding on the ProductCatalog table.
3. Create a vector index named ProductDescriptionIndex on that attribute, select Cosine distance, and set marketplace as the partition key with category as an inline filter.
4. Issue a SearchVectors request with a query vector derived from a natural‑language query, a top‑K value (≤ 100), and optional filter values (e.g., category = 'footwear').

The service delivers single‑digit millisecond latency and 99 %+ recall while scaling horizontally to trillions of vectors. Because it is fully serverless, there are no servers to provision, patch, or manage, and the same pay‑per‑request pricing model applies to both operational and vector workloads.

For teams already using DynamoDB, the recommended approach is to augment existing tables with embedding attributes and enable a vector index rather than deploying a dedicated vector store. This reduces operational overhead, eliminates synchronization complexity, and provides predictable low‑latency similarity search at any scale.

Step 1 – Prepare the table and add embeddings

Generate embeddings for the attribute you want to search (e.g., description) using one of the supported models: Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text‑embedding models. Store the result in a new attribute, such as descriptionEmbedding, using a standard PutItem or UpdateItem call. DynamoDB’s native List type holds the vector, with each element being a Number (float).

aws dynamodb update-item \
    --table-name ProductCatalog \
    --key '{"productId":{"S":"12345"}}' \
    --update-expression "SET descriptionEmbedding = :vec" \
    --expression-attribute-values '{":vec":{"L":[{"N":"0.12"},{"N":"-0.07"}, …]}}'

Step 2 – Create the vector index

In the DynamoDB console, open the table’s Indexes tab and choose Create vector index. Fill in the required fields:

• Index name: e.g., ProductDescriptionIndex
• Vector attribute: descriptionEmbedding
• Dimensions: match the output size of the embedding model (up to 4096)
• Distance function: Cosine, Euclidean, or Dot product (choose the one used during model training)
• Partition key (optional but recommended): e.g., marketplace to isolate queries per market
• Inline filter attributes: add non‑vector fields such as category for exact‑match filtering

Leave the projection set to All if you need the full item in the response, then create the index and wait for its status to become Active.

Step 3 – Execute a search

Generate a query vector from the user’s natural‑language input using the same embedding model. You can run the search either from the console or programmatically with the SearchVectors API.

aws dynamodb search-vectors \
    --table-name ProductCatalog \
    --index-name ProductDescriptionIndex \
    --query-vector file://query-vector.json \
    --k 5 \
    --partition-key-value US \
    --filter-expression "category = :cat" \
    --expression-attribute-values '{":cat":{"S":"footwear"}}'

The response contains up to 100 items (top‑K) ranked by similarity score. For Cosine and Euclidean distances, lower scores indicate higher similarity; for Dot product, higher scores indicate higher similarity.

Semantic retrieval relies on vector embeddings that capture the meaning of text, images, or signals. By storing these embeddings alongside operational attributes in a single data store, an application can issue a similarity query and receive results that are ranked by semantic closeness without a separate indexing pipeline.

Amazon DynamoDB’s native vector search enables this pattern directly on the operational table. Vectors are stored in the existing List data type, and a dedicated vector index can be created on any attribute that holds the embedding. The index supports up to 4 096 dimensions and three distance functions—Cosine, Euclidean, and Dot product—allowing the developer to match the metric used during model training. Queries are executed through the SearchVectors API, which returns the top‑K results (up to 100) together with the original item attributes.

Typical enterprise scenarios that benefit from this integration include:

• Semantic retrieval: Users search product catalogs or knowledge bases with natural language; the system returns items whose description embeddings are closest to the query embedding.
• Retrieval‑augmented generation (RAG): A generation model queries DynamoDB for context documents, reducing latency compared to fetching from a separate vector store.
• Recommendation engines: By storing user‑item interaction vectors, similarity searches can produce real‑time recommendations without an external service.
• Personalized experiences: Inline filter attributes (e.g., category or marketplace) let the same query be scoped to a segment, delivering tailored results at query time.
• Anomaly detection: Embeddings of telemetry streams are indexed; outlier vectors are identified by low similarity scores, enabling near‑real‑time alerts.

Because the vector index lives in the same serverless infrastructure as the operational data, the following operational benefits are realized:

• Elimination of data‑movement pipelines and associated licensing costs.
• Zero server provisioning, patching, or version management, aligning with SOC 2 and ISO 27001 requirements for managed services.
• Predictable low latency—single‑digit millisecond response times with 99 %+ recall—across any scale, including trillions of vectors.
• Horizontal scaling of storage and throughput without manual sharding, supporting consistent performance under high query volumes.

To adopt this approach, engineers generate embeddings with a model of choice (e.g., Amazon Bedrock Titan, Cohere, or OpenAI), store them via a standard PutItem or UpdateItem call, create a vector index specifying the dimension count and distance function, and then issue SearchVectors requests with optional filter conditions. This workflow removes the need for a separate vector database, reduces operational overhead, and maintains a unified security and compliance posture.