Skip to Content

DynamoDB: Managed NoSQL Key/Value

When to use

Single-digit-ms, infinitely scalable key-value without managing shards.

Analogy

DynamoDB is a card-catalog with magic shelves - you give it a Partition Key; it shuffles the card and finds it from a million shelves.

Data-flow diagram

  Table: Orders
      Partition Key: order_id
      Sort Key: created_at  (optional)
      Attributes: user_id, total, items[]
  Capacity: On-demand | Provisioned (RCU/WCU)
  Indexes: GSI (alternate PK); LSI (same PK, alt SK)

Deep explanation

DynamoDB tables, items, attributes. Each item has a Partition Key; optionally a Sort Key for time-series / hierarchy queries. Two capacity modes: On-Demand (per-request, automatic scaling) and Provisioned (RCU/WCU + auto-scale). GetItem by PK+SK; Query items with same PK. Scan walks entire table - use sparingly. GSI for alternate access patterns. DynamoDB Streams for change-data-capture; DAX for microsecond latency.

Examples

Example 1

aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions AttributeName=order_id,AttributeType=S \
  --key-schema AttributeName=order_id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

creates an on-demand table (pay per request; no provisioned capacity).

Example 2

aws dynamodb put-item --table-name Orders \
  --item 'file://values.json'

writes a single item; required attributes declare the schema.

Example 3

aws dynamodb query --table-name Orders \
  --key-condition-expression 'order_id = :o' \
  --expression-attribute-values '{":o":{"S":"o-001"}}'

queries items matching the partition key.

Common mistake

Using Scan for queries that Query would handle. Scan is O(N), expensive at scale. Pick a Partition Key that spreads load - all writes for one user share one partition and throttle.

Key takeaway

design access pattern first, then the keys; GSI for alternate access patterns; avoid Scan in hot paths; Streams for CDC; DAX for microsecond reads.

Production Failure Playbook

Failure scenario 1: hot-partition-throttling

Failure scenario 2: scan-instead-of-query