DynamoDB

Amazon DynamoDB is a fully managed NoSQL database that delivers consistent single-digit millisecond latency at any table size. It supports both key-value and document data models, and is used where the access patterns are known in advance and the scale is either large or unpredictable.

DynamoDB replicates every write across three Availability Zones within a Region on SSD storage. There is no instance to size, patch or fail over, and no practical limit on the number of items or the total size of a table.

What is on the other pages

• Capacity modes and scaling — on-demand versus provisioned, auto scaling, how partitions behave, and DAX.
• Partition keys — choosing a key that spreads load, and modelling relationships with composite keys.
• Consistency models and ACID properties — eventual versus strong reads, transactions, and multi-Region consistency.
• Features and quotas — indexes, TTL, batch and query operations, error handling, and the current limits.

Data model

Every item is identified by a primary key, which is either:

• a simple primary key — a single partition key attribute, unique across the table; or
• a composite primary key — a partition key plus a sort key, where the combination must be unique. Items sharing a partition key are stored together, ordered by sort key.

DynamoDB hashes the partition key to decide which physical partition holds the item, so the choice of partition key determines how evenly load is spread. That decision is covered on the partition keys page.

Beyond the key, items are schemaless: two items in the same table may carry entirely different attributes. This is what makes it practical to store several record types in one table and query them through carefully designed keys.

Read consistency

• Eventually consistent reads are the default. Updates typically propagate within a second, so a read immediately after a write may return the previous value.
• Strongly consistent reads must be requested explicitly. They reflect every write that received a successful response before the read, at the cost of higher latency, reduced availability during network problems, and twice the read capacity.

Secondary indexes

• Up to 20 global secondary indexes (GSIs) per table. A GSI may use a different partition key and sort key from the base table, and can be added or removed at any time.
• Up to 5 local secondary indexes (LSIs) per table. An LSI shares the table’s partition key with a different sort key, and can only be created when the table is created.

Each index is a second copy of the projected data with a different key schema, so indexes cost storage and write capacity as well as read capacity.

DynamoDB Accelerator (DAX)

DAX is a fully managed, highly available in-memory cache that sits in front of a table and speaks the DynamoDB API, so an application adopts it by changing its client rather than its code. It reduces read latency from milliseconds to microseconds and handles cache population and invalidation itself. The cluster runs inside a VPC you nominate, and you choose its node type and count, item and query TTLs, and maintenance window.

DAX suits read-heavy workloads with repeated lookups of the same items. It is a poor fit for write-heavy workloads — every write passes through to the table synchronously before the cache is updated, and a high write rate churns the cache through its LRU eviction and drives replication traffic between DAX nodes — and adds little to applications that already cache locally. Writes made directly to a global table replica bypass DAX, so a DAX cache in front of a global table can serve stale items until its TTL expires.

Backup and recovery

On-demand backup takes a full backup at any time, within the same Region, with no performance impact on the table.

Point-in-time recovery is optional and, once enabled, keeps continuous incremental backups covering a 35-day window with a recovery point objective of about five minutes.

Streams and replication

A stream is a time-ordered sequence of item-level modifications, divided into shards. Streams retain records for 24 hours, capture inserts, updates and deletes, and integrate directly with Lambda. See capturing data modification events.

Global tables replicate a table across Regions. Every replica accepts writes, and the table runs in one of two consistency modes — multi-Region eventual consistency, the default, or multi-Region strong consistency. Both are described on the consistency page. Global tables work with either capacity mode and require no application changes.

Security

• Encryption at rest with AWS KMS, on by default.
• IAM policies and roles, including fine-grained access control down to individual items and attributes.
• VPC endpoints for private access, and reachability over Site-to-Site VPN or Direct Connect.
• CloudWatch metrics and CloudTrail API logging.