Amazon DynamoDB is a fully managed, serverless NoSQL database service from Amazon Web Services that stores data as items addressed by a key and delivers single-digit millisecond latency at practically any scale. Among database systems, DynamoDB is the leading example of a cloud-native key-value and document store in which the provider handles servers, replication, patching and partitioning entirely.
Instead of tables joined by SQL queries, DynamoDB is built around access patterns known in advance: every efficient read targets a partition key, optionally combined with a sort key. Its design descends from the ideas in Amazon’s internal Dynamo system, but the public service, launched in 2012, uses a different architecture with synchronous replication across three Availability Zones in a region.
How DynamoDB stores and partitions data
A DynamoDB table contains items, and each item is a set of attributes of up to 400 KB in total. Only the primary key is fixed by the schema; all other attributes can vary from item to item. The primary key is either a simple partition key or a composite of a partition key and a sort key, which groups related items together and keeps them ordered.
DynamoDB hashes the partition key to decide which internal partition holds an item. Each partition is replicated to three Availability Zones and has throughput limits of roughly 3,000 read capacity units and 1,000 write capacity units per second. The service splits partitions automatically as data and traffic grow, so a well-distributed key lets a table scale almost without limit.
The building blocks below define how data is addressed and which queries can be served efficiently.
| Element | Role | Key limit or rule |
|---|---|---|
| Partition key | Determines the partition through hashing | Required on every item |
| Sort key | Orders items within a partition | Enables range queries |
| Item | One record with attributes | Up to 400 KB |
| Global secondary index | Alternative key for queries | Up to 20 per table by default |
| Local secondary index | Alternative sort key, same partition key | Up to 5, created with the table |
Capacity modes and consistency
DynamoDB charges and limits throughput in capacity units. One read capacity unit covers one strongly consistent read of up to 4 KB per second, or two eventually consistent reads; one write capacity unit covers one write of up to 1 KB per second. Tables run in one of two capacity modes, chosen per table and switchable later.
| Aspect | On-demand mode | Provisioned mode |
|---|---|---|
| Billing | Per request | Per hour of reserved capacity |
| Capacity planning | None required | Set read and write units, optionally autoscale |
| Best for | Unpredictable or spiky traffic | Steady, forecastable traffic |
| Cost at steady high load | Higher | Lower, further reduced by reservations |
| Throttling risk | Mainly on sudden extreme spikes | When traffic exceeds provisioned units |
Reads are eventually consistent by default, which usually reflects writes within about a second and costs half as much. A strongly consistent read returns the latest committed value but is not available on global secondary indexes. Since 2018, DynamoDB also offers ACID transactions across up to 100 items with TransactWriteItems and TransactGetItems, at twice the capacity cost of standard operations.
Data modeling for access patterns
Modeling for DynamoDB starts from queries, not entities. Designers list every access pattern, such as fetching an order with its lines or listing a customer’s orders by date, and then choose keys that answer each pattern with a single Query or GetItem. A `Scan` reads the entire table and is acceptable only for small tables or offline jobs.
A common technique is single-table design, in which several entity types share one table and generic key attributes such as PK and SK. Items with the same partition key, for example CUSTOMER#42, can then be retrieved together, which replaces a relational join with one efficient read. The approach is powerful but harder to read and change, and many teams use a few tables instead when access patterns are simpler.
- Choose high-cardinality partition keys such as user or device identifiers.
- Use composite sort keys like
ORDER#2026-11-11#1234to support range and prefix queries. - Add global secondary indexes only for access patterns the base key cannot serve.
- Set a time-to-live attribute to expire sessions or temporary data without write costs.
DynamoDB compared with other databases
DynamoDB trades query flexibility for predictable performance and zero operations. The comparison below places it next to systems that are often considered for the same workloads.
| System | Data model | Query flexibility | Operations burden |
|---|---|---|---|
| Amazon DynamoDB | Key-value and document | Key-based queries and indexes | Fully managed by AWS |
| Apache Cassandra | Wide-column | Key-based, CQL | Self-managed cluster or service |
| MongoDB | Document | Rich ad hoc queries and aggregation | Self-managed or managed service |
| PostgreSQL | Relational | Full SQL with joins | Server or managed instance |
| Redis | In-memory key-value | Key-based with data structures | Memory sizing required |
The closest conceptual relative is Apache Cassandra, which shares the partition-key model. PostgreSQL or MongoDB remain better choices when ad hoc queries, reporting or complex joins matter more than guaranteed latency at massive scale.
Limitations and common pitfalls
Most DynamoDB problems stem from treating it like a relational database or from keys that concentrate traffic. The following points summarize what experienced teams watch for.
- Hot partitions: a low-cardinality key such as a date or status sends most traffic to one partition and causes throttling.
- Scan-heavy code: full-table scans grow in cost and latency with every new item.
- Late-discovered access patterns: new queries may require new indexes or a data migration.
- Limited analytics: aggregations need exports to analytical services rather than queries on the table.
- Vendor lock-in: the API and pricing model are specific to AWS, which complicates moving elsewhere.
Useful supporting features include DynamoDB Streams for change data capture, point-in-time recovery for restores to any second within the last 35 days, global tables for multi-region replication and the DAX in-memory cache for microsecond reads. Each adds cost, so they should be enabled for a reason, not by habit.
A plain-language summary
Amazon DynamoDB is like a giant, extremely fast filing cabinet rented from Amazon. Each folder has a label, and as long as the label is known, the right folder is found almost instantly, whether the cabinet holds a thousand folders or billions of them.
Amazon takes care of the cabinet itself: it adds drawers, makes copies and replaces broken parts. The trade-off is that browsing through every folder is slow and expensive, so the labels must be planned around the questions the business will ask.
An example from practice
A company running a mobile game with about two million daily players stores player profiles, inventories and match results in DynamoDB. Each player’s data shares the partition key PLAYER#<id>, with sort keys such as PROFILE, ITEM#sword-17 and MATCH#2026-11-10T19:42, so loading a player’s whole state at login takes one query of a few milliseconds.
The table runs in on-demand mode because traffic jumps several times over during weekend events. A global secondary index keyed by season and score serves the leaderboard, and a time-to-live attribute removes match records after 90 days. During a large holiday event, request volume rises sharply, yet latency stays flat and no database servers need attention, letting the small backend team focus on game features.