Is DynamoDB in-memory?

No. DynamoDB is not an in-memory database — every write is persisted to durable storage and automatically replicated across three Availability Zones. When you need in-memory speed, DynamoDB Accelerator (DAX) adds a fully managed in-memory cache that cuts eventually consistent reads from single-digit milliseconds to microseconds.

Durable by design

DynamoDB is a durable operational database: writes are stored on durable media and replicated across three Availability Zones by default, backing a 99.99% availability SLA. That's the opposite trade-off from a pure in-memory store, where data lives in RAM and durability is optional.

It's still fast without a cache

Baseline DynamoDB delivers consistent single-digit-millisecond reads and writes at any scale, because every read targets a partition key directly instead of scanning. Most workloads never need a cache at all.

The one in-memory DynamoDB is the emulator

The confusion usually starts with DynamoDB Local, which does have an in-memory mode. Start it and the banner says so:

docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -inMemory -sharedDb

Initializing DynamoDB Local with the following configuration:
Port:	8000
InMemory:	true
Version:	3.3.0

Write an item, restart the container, then look for it again:

after write:            {"total":{"N":"42"},"pk":{"S":"ORDER#1"}}
tables after restart:   []
read after restart:     ResourceNotFoundException | Cannot do operations on a non-existent table

The table went with it, not just the item. That flag belongs to the test emulator. The managed service has no equivalent setting, and no mode in which an acknowledged write lives only in RAM.

DAX: the in-memory layer

When microseconds matter — real-time bidding, gaming leaderboards, hot product pages — DAX is AWS's answer: a DynamoDB-compatible, write-through, in-memory cache that improves eventually consistent read performance by an order of magnitude with minimal code changes. Skip it for strongly consistent reads or write-intensive workloads.

Paying for reads vs adding a cache

DAX saves read latency on hot keys; it does not shrink the underlying table or change write durability. Every acknowledged PutItem still lands on disk in three Availability Zones whether DAX sits in front or not. On a 10 GB table, a strongly consistent Scan bills roughly 2.5 million read request units on demand in us-east-1 — measure your own pattern with the pricing calculator before you size a cache cluster.

In DynoTable: the query preview labels Scan versus Query and shows an RCU estimate when table metadata allows it, so you can see the cost of a full read before you run it. Ordinary partition-key Query calls show no RCU line. See SQL Workbench — preview the query cost.

Go deeper

Understand the consistency trade-offs in the consistency guide, see can DynamoDB be used as a cache? for the inverse question, estimate read costs with the pricing calculator, and download DynoTable to inspect your tables.

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Reproduced 2026-07-28 against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 on Node v24.18.0. The banner and the three output lines are verbatim.