
AWS announces the general availability of vector search in Amazon DynamoDB, allowing you to store vector embeddings alongside operational data and run similarity searches with single-digit millisecond latency at 99%+ recall. No separate vector store or synchronization pipeline required—just create a vector index and start searching.
What’s Announced: Real-Time Vector Search in DynamoDB
Amazon DynamoDB has introduced native vector search, enabling the storage and retrieval of vector embeddings directly within existing operational tables. This capability eliminates the need to replicate data into specialized vector databases, thereby removing the operational overhead of maintaining synchronization pipelines, reducing data movement costs, and ensuring predictable performance for large-scale datasets.
The implementation is fully serverless, requiring no server provisioning, patching, or maintenance windows. It supports horizontal scaling to accommodate trillions of vectors without storage limits, maintaining single-digit millisecond latency at 99% recall. The system architecture leverages existing pay-per-request pricing, ensuring parity with standard DynamoDB operational patterns.
Technical implementation relies on a new index type created on an attribute storing a list of floats. Key architectural parameters include:
- Dimensions: Supports up to 4096 dimensions per vector.
- Distance Functions: Includes Euclidean (for magnitude-sensitive clustering), Cosine (for semantic similarity of text), and Dot product (for weight-aligned recommendation systems).
- Inline Filtering: Allows the application of non-vector attribute filters at query time to narrow search scopes, supporting exact-match criteria.
- Partitioning: Optional partition keys can be defined on the index to scale across distributed storage while maintaining predictable latency by scoping searches to specific data segments.
Engineers can leverage this for complex workflows, including Retrieval Augmented Generation (RAG), agentic memory, anomaly detection, and recommendation engines. To perform a search, applications utilize the SearchVectors API, providing a query vector and desired result count (Top K). The index returns results ranked by similarity according to the selected distance function. Because vector data is stored as a standard List type alongside operational data (e.g., product IDs or descriptions), no schema changes are required for existing table architectures, facilitating a seamless transition to semantic retrieval capabilities.
Why Native Vector Search Matters: No More Data Silos
Applications built on Amazon DynamoDB that needed semantic retrieval historically faced an architectural barrier: vector embeddings had to be copied into a dedicated vector database, while a separate synchronization pipeline kept both systems aligned. This split-storage design introduced significant operational burden. The pipeline demanded change-data-capture logic, batch ETL jobs, and reconciliation scripts to handle partial failures. Each component added monitoring, alerting, and tuning overhead. Duplicating data meant paying for two storage systems, network egress for the transfer, and additional write capacity to load vectors into the secondary store. Licensing costs compounded the problem, as dedicated vector databases often charge per node, per cluster, or per quantity of indexed vectors independent of actual query usage. Predictable low latency was also difficult to maintain at scale because the application had to wait for the pipeline to converge before search results reflected recent writes, and any sync lag or backpressure degraded freshness and increased p95 response times.
DynamoDB now supports native vector search, so this replication layer is unnecessary. Vector embeddings can be stored directly in a DynamoDB table as a List of Numbers, a standard data type, alongside ordinary operational attributes. After generating embeddings with a model such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text embedding models, you add them with a normal PutItem or UpdateItem call. You then create a vector index on that attribute, specify the number of dimensions (up to 4096), select a distance function (Euclidean, Cosine, or Dot product), and optionally add a partition key and inline filters. The SearchVectors API accepts a query vector, returns up to 100 ranked results, and supports non-vector filter attributes for narrowing results, such as category or marketplace.
Because vectors and operational data share the same serverless infrastructure and pay-per-request pricing model, you eliminate the separate vector store and its associated costs:
- No additional infrastructure: no servers to provision, patch, or manage, and no software to install, maintain, or operate.
- No synchronization pipeline: there is no second system to keep consistent; writes to the table are immediately searchable through the vector index.
- No separate licensing fees: pricing follows the existing DynamoDB pay-per-request model rather than per-vector or per-cluster licensing.
- Predictable scale: vector indexes scale horizontally, have no storage limits, and are designed for single-digit millisecond latency at 99%+ recall, even at trillions of vectors.
For example, a product catalog table containing productId, name, price, and description can also hold a descriptionEmbedding attribute. After creating a vector index with Cosine distance and adding an inline filter on category, a natural language query like “lightweight running shoes for summer” can be embedded and searched directly within the same table, returning ranked products alongside their operational attributes. This approach directly addresses the use cases of agentic memory, retrieval augmented generation, recommendation engines, and anomaly detection without forcing a second database into the architecture.
How Vector Search Works in DynamoDB
Vector embeddings are stored in DynamoDB using the existing List data type; each element is a Number representing a single float value of the embedding vector. This requires no new data type or schema change. Generate embeddings externally with a model such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text embedding models, then write them to the table with a standard PutItem call for new items, or an UpdateItem call to add the attribute to existing items.
After the embedding attribute exists, create a vector index on it. The index configuration requires the vector attribute name, the number of dimensions (which must match the output dimensionality of the embedding model), and a distance function. The vector index has no storage limit and scales horizontally as data grows. You can also specify non-vector attributes as inline filters to narrow search results at query time, and an optional partition key that controls how vectors are distributed across partitions. A search is scoped to a single partition key value, so an index serving multiple marketplaces can query one marketplace without scanning the full index. Filter conditions support exact-match values only; range conditions such as BETWEEN or BEGINS_WITH are not supported.
DynamoDB supports up to 4096 dimensions and three distance functions:
- Euclidean: measures straight-line distance; use when vector magnitude is meaningful, such as clustering items by a numeric value.
- Cosine: measures the angle between vectors rather than magnitude; effective for comparing semantic similarity of text embeddings.
- Dot product: considers both direction and magnitude; use in recommendation systems that weight interest alignment and frequency together.
As a general rule, match the distance function to the one used to train the embedding model for best accuracy.
The SearchVectors API accepts a query vector, the number of results to return (up to 100), and optional filter conditions. It returns results ranked by similarity. For Cosine and Euclidean distance functions, lower similarity score values indicate higher similarity, with a score of 0 indicating identical vectors. For Dot product, higher similarity score values indicate higher similarity.
Getting Started: Adding Vector Search to an Existing Table
To add semantic search to an existing DynamoDB table, you first generate vector embeddings for text attributes already present in your items. For example, an online sporting goods store might have a ProductCatalog table with productId, category, description, marketplace, name, and price. Using Amazon Bedrock Titan Text Embeddings or another embedding model, produce a numerical vector that captures the meaning of each description.
Add the embedding to each existing item as a new attribute, such as descriptionEmbedding, via an UpdateItem call. DynamoDB stores these vectors using its existing List data type; each element in the list is a Number representing a single float value of the embedding. No new data type or schema change is required.
After storing embeddings, create a vector index in the DynamoDB console. On the Indexes tab for the table, choose Create vector index and configure:
- Index name:
ProductDescriptionIndex - Vector attribute:
descriptionEmbedding - Dimensions: matching the embedding model’s output (up to 4096)
- Distance function:
Cosinefor semantic text similarity; alternativelyEuclideanwhen magnitude matters, orDot productfor direction and magnitude. As a general rule, choose the distance function used when training your embedding model. - Partition key:
marketplaceto scope searches to a single partition key value - Inline filter attributes:
categoryto narrow results at query time. Inline filters accept exact-match values only; range conditions such asBETWEENorBEGINS_WITHare not supported. - Attribute projections:
Allto return all table attributes with search results
Wait for the index status to become Active.
To run a search, generate a query vector from a natural language phrase using the same embedding model. In the console, select Search mode, choose ProductDescriptionIndex, paste the query vector, set Top K to 5, enter a partition key value like US, and apply the inline filter category = footwear. DynamoDB returns the five most semantically similar products with their standard attributes. With Cosine or Euclidean, lower similarity scores indicate higher similarity; with Dot product, higher scores indicate higher similarity.
Creating a Vector Index and Running Semantic Queries
Vector search in Amazon DynamoDB enables similarity retrieval by indexing embeddings—numerical representations of data—directly alongside operational attributes. Before creating an index, you must generate these embeddings using a machine learning model, such as Amazon Bedrock Titan Text Embeddings, and store them as a List of floats in your table. The index leverages these embeddings to perform k-nearest neighbor (k-NN) searches with sub-millisecond latency.
Configuring a Vector Index
To initialize the index within the DynamoDB console, navigate to your target table and access the Indexes tab. Select Create vector index and configure the following parameters:
- Index name: Define a unique identifier (e.g.,
ProductDescriptionIndex). - Vector attribute: Specify the attribute containing your embedding list.
- Dimensions: Input the dimensionality outputted by your embedding model (supports up to 4096).
- Distance function: Select the function corresponding to your model's training: Cosine (for angular similarity), Euclidean (for magnitude-based distance), or Dot product.
- Partition key: Optional but recommended for high-throughput scaling. This restricts the search scope to a specific data segment (e.g.,
marketplace). - Inline filter attributes: Add attributes such as
categoryto enable exact-match filtering during query execution.
Executing Semantic Queries
Once the index status reaches Active, initiate searches by switching to vector search mode within the Explore items view. Provide a query vector generated by the identical model used for ingestion, then define your search parameters:
- Top K: Specify the number of results to retrieve (maximum of 100).
- Partition key: Provide the specific value to scope the search domain.
- Filters: Apply exact-match conditions on designated inline attributes.
The system returns results ranked by similarity score. Note that for Cosine and Euclidean functions, lower scores indicate higher similarity, whereas higher scores indicate greater similarity for Dot product operations.
Availability, Pricing, and How to Get Started
Vector search in Amazon DynamoDB is generally available in all commercial AWS Regions, including AWS GovCloud (US) Regions. For granular regional availability details and the service roadmap, consult the AWS Capabilities by Region page. Pricing follows the existing DynamoDB pay-per-request model and does not introduce a separate vector storage charge; current rates are published on the Amazon DynamoDB pricing page.
DynamoDB vector search stores vector embeddings directly in your table as a List of Number values alongside existing operational attributes. This removes the need to replicate data to a separate vector database or operate a synchronization pipeline between services. The service is fully serverless with no versions, maintenance windows, or storage limits on the vector index, and it scales horizontally as data grows. When evaluating it, note that supported configuration options include up to 4096 dimensions, the Euclidean, Cosine, and Dot product distance functions, and inline filtering on non-vector attributes.
To add vector search to an existing table, generate embeddings for an attribute using a model of your choice, such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text embedding models, then write them with a standard PutItem or UpdateItem call. Next, create a vector index on that attribute and specify:
- The number of dimensions matching your embedding model's output.
- A distance function. Use Cosine when semantic similarity of text is the goal, because it measures the angle between vectors rather than their magnitude. Use Euclidean when vector magnitude is meaningful, such as clustering by purchase count. Use Dot product when both direction and magnitude matter, such as in recommendation systems that weight interest and frequency together. Match the distance function to the one used to train the embedding model.
- An optional partition key to scope each search to a single partition key value, which supports scaling for large datasets with high query throughput. Inline filter attributes narrow results and support exact-match values only; range conditions such as
BETWEENorBEGINS_WITHare not supported.
For example, an online sporting goods store with a ProductCatalog table stores description embeddings in a descriptionEmbedding attribute. A vector index named ProductDescriptionIndex uses the Cosine distance function and the marketplace partition key, with category as an inline filter attribute. Querying with the text "lightweight running shoes for summer" returns up to 100 results (Top K) scoped to a specific marketplace and filtered to footwear. Similarity score interpretation depends on the distance function: for Cosine and Euclidean, lower scores indicate higher similarity and 0 means identical vectors; for Dot product, higher scores indicate higher similarity.
To get started, use the DynamoDB console, AWS CLI, SDKs, CloudFormation, or other infrastructure-as-code tools. Full setup instructions are in the Amazon DynamoDB Developer Guide. Share feedback via AWS re:Post for Amazon DynamoDB or through your usual AWS Support contacts.
Editorial Policy & Research Methodology
Our findings are based on rigorous internal research, verified industry benchmarks, and direct technical implementation experience from our enterprise client projects. All statistics and technical claims are reviewed by senior engineers before publication to ensure accuracy, transparency, and helpfulness for our readers.
