Cloud Parts

Amazon DynamoDB

AWS’s serverless key-value and document database, with single-digit-millisecond reads at any size.

What it is
Key-value stores,Document databases
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026
Website

What it is

A DynamoDB table has no servers or versions for you to manage. Each item has a partition key, and optionally a sort key. DynamoDB hashes the partition key to decide which storage partition holds the item, and keeps items with the same partition key together, ordered by sort key. So “all orders for customer 1042 in October” is one Query that reads a contiguous range. Data is copied across three Availability Zones, and tables have no practical size limit.

Capacity is billed one of two ways. On-demand charges per request, so a table with no traffic pays nothing for throughput. Provisioned charges for a set number of reads and writes per second, with optional auto scaling. Secondary indexes give extra access paths. Transactions update up to 100 items atomically. DynamoDB Streams records every item change in order, which is how Lambda functions react to writes. Global tables replicate a table to several Regions, each accepting writes, with a 99.999% availability SLA.

Why teams pick it

  • Fully serverless: no instances, patches or maintenance windows, and on-demand tables pay no throughput charges when idle
  • Consistent single-digit-millisecond latency at any table size
  • Streams and Lambda triggers make event-driven designs straightforward
  • Multi-Region, multi-active global tables and point-in-time recovery for the last 35 days

Watch out for

  • No joins or ad-hoc queries: you design keys and indexes around known access patterns
  • Items are at most 400 KB, and each Query or Scan call returns at most 1 MB
  • A transaction covers at most 100 items and 4 MB, and isn’t atomic across Regions in a global table
  • AWS-only, with its own API; moving off it means rewriting the data layer

Alternatives

What all key-value stores have in common →
Amazon ElastiCacheAWSAWS’s managed Valkey, Redis OSS and Memcached, as node-based clusters or a serverless cache.Amazon MemoryDBAWSA Valkey- and Redis-compatible database that keeps everything in memory but loses no acknowledged write.FoundationDBOpen sourceAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.MemcachedOpen sourceA simple, multithreaded in-memory key-value cache; clients hash keys across independent servers.RedisOpen sourceAn in-memory data-structure server: the default cache, and also queues, counters and leaderboards.RocksDBOpen sourceThe embedded key-value engine Facebook forked from LevelDB: an LSM tree in a C++ library that many databases and stream processors use as their storage layer.ValkeyOpen sourceThe Linux Foundation’s BSD-licensed fork of Redis 7.2.4: an in-memory key-value server that Redis clients can talk to unchanged.Workers KVCommercialCloudflare’s global key-value store that keeps data in a few central stores and caches it in the data centers where it is read, so reads are fast and writes take up to a minute to show up everywhere.

How it fits with other technologies

What uses Amazon DynamoDB

An on-demand table keyed by customer and time, queried by range · bash

aws dynamodb create-table --table-name orders --billing-mode PAY_PER_REQUEST \
  --attribute-definitions AttributeName=customer_id,AttributeType=S AttributeName=order_ts,AttributeType=S \
  --key-schema AttributeName=customer_id,KeyType=HASH AttributeName=order_ts,KeyType=RANGE

aws dynamodb put-item --table-name orders --item \
  '{"customer_id":{"S":"c#1042"},"order_ts":{"S":"2026-10-05T09:30:00Z"},"total":{"N":"59.90"}}'

# every October order for one customer, newest first
aws dynamodb query --table-name orders --no-scan-index-forward \
  --key-condition-expression "customer_id = :c AND begins_with(order_ts, :m)" \
  --expression-attribute-values '{":c":{"S":"c#1042"},":m":{"S":"2026-10"}}'

See it in a real stack

Serverless web app on AWS →
Live model
What you’re watchingPage loads go to CloudFront and are mostly cache hits; misses fetch from S3. API calls go to API Gateway, pass its throttle and run on Lambda, which reads and writes DynamoDB. Watch Lambda add instances, with cold starts in amber, when calls bunch up.
Where it came from2007–2025

During the 2004 holiday shopping season, Amazon.com suffered outages that its engineers traced back to commercial databases being pushed past their limits. Many of Amazon’s services, such as the shopping cart, only ever looked data up by primary key, so a full relational database was more than they needed and limited how far they could scale. Amazon built Dynamo, an internal key-value store that spread data across many machines and kept accepting writes even when disks failed or networks split, and described it in a 2007 paper.

Dynamo worked, but few teams wanted to run it. It did nothing to reduce the operational complexity of running large database systems, and engineers didn’t want to become experts in its moving parts across several data centers. Meanwhile AWS’s managed SimpleDB showed that developers preferred simplicity to fine-grained control, although it was limited in size and its performance was hard to predict. DynamoDB, launched on January 18, 2012, set out to combine the two: Dynamo’s incremental scalability and predictable performance, with SimpleDB’s hands-off administration and richer table model.

It now runs much of Amazon itself. On Prime Day 2021, DynamoDB served trillions of API calls, peaking at 89.2 million requests per second. Later additions such as Streams, transactions, on-demand billing and multi-Region tables filled in much of what the first version left out.

Why it’s built this way

A managed service, not software you install
Dynamo showed that good technology goes unused if every team has to operate it. SimpleDB showed developers would trade fine-grained control for not running anything.
Partition keys instead of joins and ad-hoc queries
Most Amazon services fetched data by key. Hashing that key to spread items across partitions lets a table grow by adding partitions, which a relational design couldn’t do as easily.
Provisioned throughput on solid-state drives
Customers declared the reads and writes per second a table needed and DynamoDB reserved that capacity on SSDs, so latency stayed predictable and the price was clear up front. On-demand billing came later, in 2018, for spiky workloads.

Timeline

  1. 2007

    Amazon’s Dynamo paper describes its internal key-value store

  2. 2012

    DynamoDB launches on January 18

  3. 2015

    Streams, Lambda triggers and cross-Region replication become generally available

  4. 2017

    Global tables replicate a table across Regions, each accepting writes

  5. 2018

    On-demand capacity and ACID transactions announced at re:Invent

  6. 2021

    Prime Day traffic peaks at 89.2 million requests per second

  7. 2025

    Global tables gain multi-Region strong consistency

Sources14 · facts checked 5 October 2026

Improve this page on GitHub