DynamoDB Performance and Latency: Measure It, Then Reduce It

DynamoDB is designed to serve single-item reads and writes in single-digit milliseconds at any scale, measured inside the service. What your application sees is that time plus the network, TLS, SDK work and any retries, so the first step with slow requests is to separate the two. The CloudWatch metric SuccessfulRequestLatency shows DynamoDB's side, with p99 and other percentiles since March 2025, and the gap to your own client-side timing is everything else. For reads that need microseconds, DynamoDB Accelerator (DAX) caches items in memory.

What drives the latency of each operation

How to measure DynamoDB latency

On the server: SuccessfulRequestLatency

SuccessfulRequestLatency is the time DynamoDB spent on successful requests, in milliseconds, per table and operation (the TableName and Operation dimensions). It doesn't include network latency or anything that happens in your client. Since March 27, 2025 it supports percentile statistics, so alarm on p99 rather than on Average, which hides the slow tail. You can type custom percentiles such as p99.9 into the CloudWatch statistic field.

aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name SuccessfulRequestLatency \
  --dimensions Name=TableName,Value=orders Name=Operation,Value=GetItem \
  --start-time 2026-10-22T00:00:00Z \
  --end-time 2026-10-23T00:00:00Z \
  --period 300 \
  --extended-statistics p50 p99
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name SuccessfulRequestLatency \
  --dimensions Name=TableName,Value=orders Name=Operation,Value=GetItem \
  --start-time 2026-10-22T00:00:00Z \
  --end-time 2026-10-23T00:00:00Z \
  --period 300 \
  --extended-statistics p50 p99

The other DynamoDB metrics worth having on the same dashboard:

Dynobase shows a table's capacity usage, throttling and latency in a Metrics tab next to its data, if you want them without opening CloudWatch.

In your application

Time the call and look at how many attempts the SDK made. In the AWS SDK for JavaScript v3 every response carries $metadata.attempts and $metadata.totalRetryDelay, so you can tell a slow DynamoDB from a request that was retried:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb"

// Create the client once, outside any request handler, and reuse it.
const client = DynamoDBDocumentClient.from(new DynamoDBClient({}))

const started = performance.now()
const { Item, $metadata } = await client.send(
  new GetCommand({
    TableName: "orders",
    Key: { pk: "customer#123", sk: "order#2026-10-23#0001" },
  })
)
console.log({
  found: Boolean(Item),
  elapsedMs: Math.round(performance.now() - started),
  attempts: $metadata.attempts,
  retryDelayMs: $metadata.totalRetryDelay,
})
import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb"

// Create the client once, outside any request handler, and reuse it.
const client = DynamoDBDocumentClient.from(new DynamoDBClient({}))

const started = performance.now()
const { Item, $metadata } = await client.send(
  new GetCommand({
    TableName: "orders",
    Key: { pk: "customer#123", sk: "order#2026-10-23#0001" },
  })
)
console.log({
  found: Boolean(Item),
  elapsedMs: Math.round(performance.now() - started),
  attempts: $metadata.attempts,
  retryDelayMs: $metadata.totalRetryDelay,
})

If your timing is far above SuccessfulRequestLatency for the same operation, the time is going to connection setup, the network path, retries or your own code, not to DynamoDB.

What makes DynamoDB requests slow

• New connections. For a short call such as a GetItem, opening a TCP and TLS connection can take longer than the operation itself. Create one client and reuse it; in AWS Lambda, create it outside the handler. The AWS SDK for JavaScript v3 keeps connections alive by default (v2 needed AWS_NODEJS_CONNECTION_REUSE_ENABLED=1).
• Distance. Every request from another Region crosses the network twice. Run the application in the table's Region, and use global tables to put a replica near users in other Regions.
• Large items and big pages. Bigger items take longer to read, write and transfer. Attribute names count toward item size, so long names on millions of items add up. ProjectionExpression trims what comes back over the network, though you still pay read capacity for the full items.
• Scans and filters. A Scan reads every item, and a FilterExpression is applied after the read, so filtering does not reduce read capacity; it can still reduce response size. Query by key or through an index instead; see Scan vs Query.
• Throttling. A throttled request is retried with exponential backoff, which shows up as latency long before it shows up as errors. DynamoDB throttling covers the causes and fixes.
• Strong consistency and transactions. Strongly consistent reads cost twice the read units and might be slower. Transactions do two reads or writes per item. Use them where you need them, not by default; see read consistency.
• Under-provisioned GSIs. In provisioned mode, a GSI with less write capacity than its table can throttle, delay propagation to the index, and throttle writes to the table itself. Size each GSI for the writes that affect it and the size of its projected items; a sparse index need not match the table's capacity.

How to reduce latency

1. Reuse clients and connections, and keep the SDK current.

2. Set timeouts so a stuck request fails fast and gets retried instead of hanging:

   import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
   import { NodeHttpHandler } from "@smithy/node-http-handler"
   
   const client = new DynamoDBClient({
     maxAttempts: 3,
     requestHandler: new NodeHttpHandler({
       connectionTimeout: 1000,
       requestTimeout: 2000,
     }),
   })
   import { DynamoDBClient } from "@aws-sdk/client-dynamodb"
   import { NodeHttpHandler } from "@smithy/node-http-handler"
   
   const client = new DynamoDBClient({
     maxAttempts: 3,
     requestHandler: new NodeHttpHandler({
       connectionTimeout: 1000,
       requestTimeout: 2000,
     }),
   })
   

3. Read by key. Design keys and GSIs so every frequent access pattern is a GetItem or a Query, not a Scan.

4. Use eventually consistent reads wherever a read doesn't have to see a write from the last second.

5. Keep items small. Store large blobs in Amazon S3 with a pointer in the item, and return only the attributes you need.

6. Fetch in parallel. Send independent reads concurrently, or batch them with BatchGetItem, instead of one after another.

7. Pre-warm before known peaks with warm throughput, so the table doesn't throttle while it scales.

8. Keep traffic private and direct. A gateway VPC endpoint sends DynamoDB traffic from your VPC without a NAT gateway or internet gateway. Interface endpoints (AWS PrivateLink) also work from on-premises networks, with up to 50,000 requests per second per endpoint.

9. Cache hot reads. DAX serves cached, eventually consistent reads in microseconds and is API-compatible with DynamoDB.

DynamoDB compared with in-memory stores

DynamoDB keeps every item on SSD-backed storage replicated across three Availability Zones, which is what makes its writes durable and also why it answers in milliseconds rather than microseconds. In-memory services such as DAX and Amazon ElastiCache (Valkey, Redis OSS or Memcached) answer from RAM in microseconds, but they are caches in front of a database, not a replacement for one. If a workload needs both durability and microsecond reads, the usual design is DynamoDB as the source of truth with a cache in front; the comparison pages for DynamoDB vs Redis and DynamoDB vs ElastiCache go through the trade-offs.