Amazon DynamoDB FAQs

DynamoDB is a fast and flexible nonrelational database service for any scale. DynamoDB enables customers to offload the administrative burdens of operating and scaling distributed databases to Amazon Web Services so that they don’t have to worry about hardware provisioning, setup and configuration, throughput capacity planning, replication, software patching, or cluster scaling.

DynamoDB takes away one of the main stumbling blocks of scaling databases: the management of database software and the provisioning of the hardware needed to run it. You can deploy a nonrelational database in a matter of minutes. DynamoDB automatically scales throughput capacity to meet workload demands, and partitions and repartitions your data as your table size grows. Also, DynamoDB synchronously replicates data across three facilities in an Amazon Web Services China Region, giving you high availability and data durability.

When reading data from DynamoDB, users can specify whether they want the read to be eventually consistent or strongly consistent:

• Eventually consistent reads (the default) – The eventual consistency option maximizes your read throughput. However, an eventually consistent read might not reflect the results of a recently completed write. All copies of data usually reach consistency within a second. Repeating a read after a short time should return the updated data.

• Strongly consistent reads — In addition to eventual consistency, DynamoDB also gives you the flexibility and control to request a strongly consistent read if your application, or an element of your application, requires it. A strongly consistent read returns a result that reflects all writes that received a successful response before the read.

• ACID transactions – DynamoDB transactions provide developers atomicity, consistency, isolation, and durability (ACID) across one or more tables within a single Amazon Web Services account and region. You can use transactions when building applications that require coordinated inserts, deletes, or updates to multiple items as part of a single logical business operation.

DynamoDB supports GET/PUT operations by using a user-defined primary key. The primary key is the only required attribute for items in a table. You specify the primary key when you create a table, and it uniquely identifies each item. DynamoDB also provides flexible querying by letting you query on nonprimary key attributes using global secondary indexes and local secondary indexes.

A primary key can be either a single-attribute partition key or a composite partition-sort key. A single-attribute partition key could be, for example, UserID. Such a single attribute partition key would allow you to quickly read and write data for an item associated with a given user ID.

DynamoDB indexes a composite partition-sort key as a partition key element and a sort key element. This multipart key maintains a hierarchy between the first and second element values. For example, a composite partition-sort key could be a combination of UserID (partition) and Timestamp (sort). Holding the partition key element constant, you can search across the sort key element to retrieve items. Such searching would allow you to use the Query API to, for example, retrieve all items for a single UserID across a range of time stamps.

After you have created a table using the DynamoDB console or CreateTable API, you can use the PutItem or BatchWriteItem APIs to insert items. Then, you can use the GetItem, BatchGetItem, or, if composite primary keys are enabled and in use in your table, the Query API to retrieve the items you added to the table.

Yes. DynamoDB is a fully managed cloud service that you access via API. Applications running on any operating system (such as Linux, Windows, iOS, Android, Solaris, AIX, and HP-UX) can use DynamoDB. We recommend using the Amazon Web Services SDKs to get started with DynamoDB.

Each DynamoDB table has provisioned read-throughput and write-throughput associated with it. You are billed by the hour for that throughput capacity if you exceed the Amazon Web Services China (Ningxia) Region Free Tier. Note that you are charged by the hour for the throughput capacity, whether or not you are sending requests to your table. If you would like to change your table’s provisioned throughput capacity, you can do so using the Amazon Web Services Management Console, the UpdateTable API for auto scaling. Also, DynamoDB charges for data storage as well as the standard internet data transfer fees.

To learn more about DynamoDB pricing, see the DynamoDB pricing page.

Maximum throughput per DynamoDB table is practically unlimited. For information about the limits in place, see Limits in DynamoDB.  

The smallest provisioned throughput you can request is 1 write capacity unit and 1 read capacity unit for both auto scaling and manual throughput provisioning. Such provisioning falls within the Amazon Web Services China (Ningxia) Region Free Tier which allows for 25 units of write capacity and 25 units of read capacity. The Amazon Web Services China (Ningxia) Region Free Tier applies at the account level, not the table level. In other words, if you add up the provisioned capacity of all your tables, and if the total capacity is no more than 25 units of write capacity and 25 units of read capacity, your provisioned capacity would fall into the Amazon Web Services China (Ningxia) Region Free Tier.

For more information about data models and APIs, see Amazon DynamoDB: How It Works.

For information about scalability, availability, and durability, see Amazon DynamoDB Product Details.

For information about DynamoDB auto scaling, see Managing Throughput Capacity Automatically with DynamoDB Auto Scaling.

For information about DynamoDB security and control, see Authentication and Access Control for Amazon DynamoDB.

Vector search in DynamoDB introduces a new index you create on the attribute that stores vector embeddings. This index is based on a proprietary approximate nearest neighbor (ANN) algorithm optimized for efficiency and horizontal scalability. It supports three distance metrics including Euclidean, cosine and dot product, and inline filtering. Vector embeddings stored in DynamoDB support up to 4096 dimensions. You generate vector embeddings using a model of your choice, such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI text embedding models, and store them as a list of floats in your table using a standard PutItem call. Vector search in DynamoDB works with DynamoDB global tables (both Multi-Region Eventual Consistency and Multi-Region Strong Consistency) and DynamoDB Streams. To learn more, visit vector search documentation for DynamoDB.

Choose DynamoDB vector search when you need single-digit millisecond vector search at any scale in a serverless database with zero infrastructure management. By using native vector search of DynamoDB, you also avoid adding a separate vector database and don’t need a data pipeline to synch operational data to it.

First, you ‘vectorize’ or generate vector embeddings for your data using a model of your choice such as Amazon Bedrock Titan Text Embeddings, Titan Multimodal Embeddings, Cohere Embed, OpenAI’s Text Embedding Models, or a custom model. You can vectorize data already existing in DynamoDB or bring your own embeddings. You can store these vector embeddings in DynamoDB as attributes using existing DynamoDB data types, such as an array of numbers (float). With just a few clicks on the Amazon Web Services Management Console, or using the Amazon SDK, Amazon CLI, or Amazon CloudFormation, you create a new vector index on the attributes that have the vector embeddings and optionally choose to specify attributes you want to filter by, so that you can reduce the search space for faster queries. Once the index is created, you can use the search API to perform similarity search on the index with predictable performance at scale. To perform search, you vectorize the search term using the same model you used to vectorize the data. You then query the vector index using the vectorized search term and the filter criteria, if applicable.

You can use existing data types to store vector embeddings in DynamoDB. For example, you can store vectors as an array of floats.

DynamoDB vector search supports three distance functions including Euclidean, cosine, and dot product. These quantify how far apart two vectors are in a given space. Euclidean measures straight-line distance between points and useful when magnitude matters (e.g., clustering items by purchase count). Cosine measures the angle between vectors and is used when direction matters more than magnitude (e.g., comparing a tweet to a document on the same topic). Dot product combines alignment and magnitude and is useful when both matter (e.g., recommendation systems considering interest alignment and frequency). Choosing the right distance function depends on your data, embedding model, and use case. In general, you must match the distance function to the one used to train your embedding model for the highest accuracy.

Yes. You can perform ENN search using the DynamoDB scan operation on the table. The exact nearest neighbor (ENN) search prioritizes accuracy over speed by looking for exact matches to a query vector. You can perform a repeated paginated scan to get exact matches to your search query.

Vectors with up to 4,096 dimensions are supported. Vector indexes are supported with on-demand tables only. Searches support up to 100 top k results. You can create up to five vector indexes per table. You can request an increase to the five vector index service quota by reaching out to Amazon Web Services Support. For more detail, see our documentation.

How do I improve accuracy or search query recall?

If your data has changed since the creation of the index, you can create a new index to improve search query recall. Creating a new index may result in optimized indexing structure for your query patterns and provide better search query recall. You can cutover your application from the old index to use the new one. The new index will have a different ARN. Once the applications querying the vector index have cutover from the old index, you can choose to delete the old index.