Amazon DynamoDB
A fully managed NoSQL database service that guarantees single-digit millisecond latency and automatically scales to handle any level of traffic
Overview
Amazon DynamoDB is a fully managed NoSQL database service that supports both key-value and document data models. AWS states that the service delivers single-digit millisecond response times, and that this response profile holds as data volume and request rates grow. After creating a table, you can choose between two billing modes: on-demand mode, which delegates capacity management to AWS, and provisioned mode, which lets you specify throughput in advance. As of September 2026, the AWS documentation states that the Global Tables feature replicates data automatically across multiple Regions, enabling a multi-Region configuration with read and write access in each Region. DynamoDB Streams captures table changes in real time, allowing you to run event-driven processing with Lambda functions.
Partition Key Design and Avoiding Hot Partitions
A DynamoDB table has a primary key consisting of a partition key and an optional sort key. Data is internally distributed across storage partitions based on the partition key value, making partition key design one of the most consequential factors for performance. Choosing a high-cardinality attribute (such as user ID, order ID, or device ID) as the partition key helps spread data and requests evenly across partitions. Conversely, using a low-cardinality attribute (such as date, status, or category) as the partition key causes the hot partition problem, where read and write traffic concentrates on a small number of partitions, leading to throttling even when overall table capacity is sufficient. For access patterns that inherently have low cardinality, a common mitigation is to append a random suffix to the partition key (write sharding) and fan out reads across the sharded keys. Global Secondary Indexes (GSIs) enable efficient queries on attributes other than the primary key, but each GSI consumes additional storage and write throughput proportional to the projected attributes, so it is important to keep them to a minimum and project only the attributes you need.
Criteria for Choosing Between On-Demand and Provisioned Modes
DynamoDB offers two capacity modes with fundamentally different cost and scaling characteristics. On-demand mode delegates capacity management to AWS and scales without capacity planning, within the per-table throughput quotas that AWS documents (as of September 2026). Because you pay only for the read and write request units you consume - see the official Amazon DynamoDB pricing page for current rates - it suits unpredictable or spiky workloads, new applications whose traffic patterns are unknown, and development and test environments. Provisioned mode lets you specify read and write capacity units in advance, with Auto Scaling adjusting capacity based on utilization targets. It can be considerably cheaper for steady-state workloads at sustained high throughput; compare the two modes on the official pricing page against your own traffic profile. The decision criteria are straightforward: use on-demand when traffic is unpredictable or bursty, and switch to provisioned mode once traffic patterns stabilize and you can forecast capacity needs. Azure Cosmos DB bills in Request Units, whose consumption per operation depends on data size and query complexity, while DynamoDB consumes read and write request units according to the item-size thresholds defined in its own documentation. Both models are revised over time, so check each vendor's official pricing documentation before comparing them.
Operational Optimization with DAX, TTL, and Backups
DynamoDB Accelerator (DAX) is an in-memory caching layer purpose-built for DynamoDB; AWS states that it brings read latency down from milliseconds to microseconds (as of September 2026). DAX exposes an API compatible with DynamoDB's, so many designs can point the client at the DAX cluster endpoint with limited code change. It is most effective for read-heavy workloads with repeated access to the same items, such as session stores, product catalogs, and leaderboards. AWS states that the TTL (Time to Live) feature deletes expired items at no additional cost (as of September 2026), making it a practical fit for time-sensitive data such as session records, temporary tokens, and event logs without manual cleanup scripts. For data protection, Point-in-Time Recovery (PITR) allows you to restore a table to any second within the past 35 days, providing fine-grained recovery from accidental writes or deletes. Combining PITR with on-demand backups (which are retained indefinitely until explicitly deleted) provides comprehensive data protection. DynamoDB Streams captures item-level changes in real time, enabling event-driven architectures where Lambda functions react to data changes for tasks like updating search indexes, sending notifications, or replicating data to other stores.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.