How fast is DynamoDB?

Fast. DynamoDB delivers consistent single-digit-millisecond read and write latency at any scale. Adding DynamoDB Accelerator (DAX), an in-memory cache, cuts eventually consistent reads to microseconds. Performance stays flat as tables grow because reads target a partition key directly rather than scanning, so latency does not degrade with data volume.

Why it stays fast at scale

A GetItem or Query hashes the partition key and goes straight to the right physical partition. It never scans the whole table, so response time is roughly constant whether the table has thousands or billions of items.

Microsecond reads with DAX

DAX is a fully managed, DynamoDB-compatible in-memory cache that fronts your table. It returns eventually consistent reads in microseconds — up to a 10x improvement over milliseconds — with no cache invalidation to manage. It is not a fit for workloads that need strongly consistent reads.

The number your users actually see

Single-digit milliseconds is measured at the DynamoDB endpoint. What your application experiences is that plus the network, and the network is usually the larger half by a wide margin.

Measured from one machine in Spain on 2026-07-28, nine samples per Region, median TCP handshake to each regional DynamoDB endpoint. That is one round trip, before a single byte of request is sent:

One machine, one ISP, one afternoon, so read these as orders of magnitude rather than a benchmark. Two things in them hold generally. A transatlantic round trip is more than ten times the read it carries, so at that distance DynamoDB's latency is a rounding error in yours. And the Region geographically closest to the machine was not the fastest one from it: eu-south-2 sits in Spain and measured no better than Frankfurt, because routing, not distance, decides.

The practical version is that co-locating compute with the table beats any DynamoDB tuning you can do. A Lambda function in the table's Region pays a fraction of the numbers above; a laptop or a CI job on another continent pays all of them on every connection, which is also why SDK connection reuse matters more than it looks.

What can slow you down

• Scans and filters — reading the whole table is slow and costly; design key-based access instead.
• Hot partitions — when one partition key draws far more traffic than its share, requests against it throttle even though overall table capacity is fine.

Good key design, not more hardware, is what keeps DynamoDB fast.

Go deeper

Read query vs scan and avoid a hot partition. Download DynoTable to see which reads run as Query vs Scan.

References

• Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
• In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
• What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
• Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide

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

Latency figures measured 2026-07-28 from a single machine in Spain with curl, nine requests per Region, reporting the median of time_connect minus time_namelookup against https://dynamodb.<region>.amazonaws.com. Two independent runs agreed to within 3 ms.