Amazon DynamoDB Now Supports Real‑Time Vector Search at Any Scale

Amazon DynamoDB’s general‑availability (GA) release adds a native vector‑search index type, allowing applications to store high‑dimensional embeddings directly alongside their existing operational attributes. Vectors are persisted using DynamoDB’s standard List data type, where each element is a floating‑point number, so no schema change or custom data type is required.

The service promises single‑digit millisecond query latency with ≥ 99 % recall, and it scales horizontally to support “any scale,” including trillions of vectors. Because the index is built on DynamoDB’s server‑less infrastructure, there are no servers to provision, patch, or manage, and the same pay‑per‑request pricing model applies to both key‑value and vector operations.

Key technical characteristics

• Maximum dimensionality: 4096 dimensions per vector.
• Supported distance functions: Euclidean, Cosine, and Dot‑product. Selecting the same metric used during model training yields the best accuracy.
• Query API (SearchVectors) accepts a query vector, a top‑K limit (up to 100), and optional exact‑match filter conditions on non‑vector attributes.
• Optional partition key for the vector index improves distribution and enables per‑partition query scoping, which is useful for multi‑tenant or multi‑marketplace workloads.
• Inline filter attributes (e.g., category) allow additional narrowing of results without a separate scan.

Practical integration example

Consider an existing ProductCatalog table that stores productId, name, price, and description. To add semantic search:

1. Generate a text embedding for each description using a model such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI embeddings.
2. Update each item with a new attribute, e.g., descriptionEmbedding, via UpdateItem. The attribute holds the embedding as a list of floats.
3. Create a vector index:
   • Name: ProductDescriptionIndex
   • Vector attribute: descriptionEmbedding
   • Dimensions: match the model output (e.g., 1536)
   • Distance function: Cosine
   • Partition key: marketplace (optional but recommended for large datasets)
   • Inline filter attribute: category
4. Execute a search by sending a query vector derived from a user’s natural‑language phrase (e.g., “lightweight running shoes for summer”) to SearchVectors, specifying TopK=5, the appropriate partition key value, and a category = 'footwear' filter.

The response returns the five most similar products, ordered by similarity score, together with the standard attributes (name, price, etc.). This workflow eliminates the need for a separate vector database and the associated data‑synchronisation pipeline, while preserving DynamoDB’s durability, security (e.g., SOC 2, ISO 27001 compliance), and operational simplicity.

Before adding vector search, understand that a vector embedding is a fixed‑length list of floating‑point numbers that represents the semantic meaning of a text field. Two items with similar descriptions will have embeddings that are close in the chosen distance space, enabling similarity queries.

1. Prepare the DynamoDB table. Use the existing ProductCatalog table, which already stores attributes such as productId, category, description, marketplace, name, and price. For each item, generate an embedding for the description field with a model that matches your application’s latency and cost profile (e.g., Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text‑embedding‑ada‑002). Store the result in a new attribute called descriptionEmbedding using an UpdateItem call; DynamoDB’s native List type holds the float values, so no schema change is required.
2. Create the vector index. In the DynamoDB console, open the ProductCatalog table and select the Indexes tab → Create vector index. Configure the index as follows:
   • Index name: ProductDescriptionIndex
   • Vector attribute: descriptionEmbedding
   • Dimensions: match the output size of the embedding model (up to 4096 supported)
   • Distance function: Cosine (recommended for text embeddings; alternatives are Euclidean and Dot product)
   • Partition key: marketplace (optional but improves scaling for multi‑marketplace catalogs)
   • Inline filter attributes: add category to enable exact‑match filtering at query time
   • Attribute projection: All to return the full item payload with search results
   After confirming, wait for the index status to become Active.
3. Run a sample search. Generate a query vector from a natural‑language phrase such as “lightweight running shoes for summer” using the same embedding model. In the console, navigate to Explore items, select ProductCatalog, and switch to vector‑search mode. Choose ProductDescriptionIndex, paste the query vector, set Top K to 5, and provide:
   • Partition key value: US (to limit the search to the US marketplace)
   • Filter: category = footwear
   Execute the query. DynamoDB returns the five most similar items, ordered by the cosine similarity score (lower scores indicate higher similarity). The response includes standard attributes like name and price, eliminating the need for a separate vector store.

Programmatic access follows the same pattern via the SearchVectors API, which accepts the query vector, TopK, and optional filter conditions. This workflow lets engineers add semantic retrieval to an existing DynamoDB workload without provisioning additional infrastructure.

Native vector search enables enterprises to perform high-dimensional similarity operations directly on operational data, eliminating the need for separate synchronization pipelines or auxiliary vector databases. By storing embeddings—numerical representations of semantic meaning—alongside transactional data, systems can execute low-latency similarity queries while maintaining data consistency. This architecture simplifies the stack for applications requiring sophisticated pattern matching and high-throughput retrieval.

Common technical implementations include:

• Semantic Retrieval for Agentic Memory: Enabling autonomous agents to query past interactions or technical documentation by converting natural language queries into vectors, allowing for retrieval based on context rather than exact keyword matches.
• Retrieval-Augmented Generation (RAG): Integrating vector search to retrieve relevant, up-to-date context from operational stores to augment large language model prompts, thereby reducing hallucinations and increasing factual grounding.
• Recommendation Engines: Utilizing vector distance functions to identify products or content that share high semantic similarity with user preferences, weighting interest alignment through specific distance metrics.
• Personalized Experiences: Powering real-time content delivery by clustering user behavior vectors with item embeddings to tailor the interface dynamically.
• Anomaly Detection: Identifying deviations from baseline patterns by measuring the distance between live event vectors and established historical clusters, effectively flagging outliers in high-dimensional datasets.

To implement these, engineers must select the appropriate distance function aligned with their embedding model’s training objective. Cosine distance is standard for text similarity as it evaluates vector angle, while Euclidean distance is appropriate for clustering where magnitude is meaningful, such as purchase frequency analysis. Dot product operations are typically reserved for recommendation systems where both direction and weight intensity are prioritized. By utilizing inline filtering—applying exact-match constraints on standard non-vector attributes during the search—engineers can significantly narrow result sets without the overhead of post-processing, maintaining single-digit millisecond performance even as vector indexes scale horizontally.

Amazon DynamoDB operates as a fully serverless database, abstracting the underlying infrastructure to eliminate the need for manual server provisioning, patching, or routine maintenance. By removing these operational requirements, the service eliminates maintenance windows, ensuring zero-downtime availability. This architecture allows developers to focus on data modeling and application logic rather than cluster management or capacity planning.

The operational simplicity extends to data storage and scaling. Vector search capabilities, for example, allow storing embeddings directly alongside operational data. This integration removes the overhead of maintaining external synchronization pipelines between a database and a dedicated vector store. Key characteristics of this operational model include:

• Elastic Scaling: Infrastructure scales automatically to handle data growth, including support for trillions of vectors without predefined storage limits.
• Unified Pricing: The service utilizes a consistent pay-per-request pricing model for both operational data and vector search functions.
• Global Availability: Capabilities are deployed across all commercial AWS Regions, including AWS GovCloud (US) Regions.
• No Versioning: The service model avoids manual software updates or version management, ensuring consistent access to features as they are introduced.

From an architectural perspective, the serverless nature of the platform supports consistent latency profiles. For native vector search, the system provides single-digit millisecond latency with high recall thresholds. Developers define indices on existing table attributes—such as lists of floats representing embeddings—without requiring schema migrations or complex data type conversions. When executing queries, the SearchVectors API allows for scoped searches using partition keys, which optimizes performance by distributing vector indices across physical partitions. This design ensures that query throughput remains predictable even as datasets expand to support agentic memory or retrieval-augmented generation (RAG) workloads. By sharing the same infrastructure as core operational data, the platform minimizes data movement, reduces architectural complexity, and avoids the additional licensing costs typically associated with multi-database deployments.