← AWS Course8 / 13

DynamoDB — NoSQL at Any Scale

Learn the AWS NoSQL database by doing: create tables with the right keys, model data with single-table design, query with secondary indexes, react to changes with streams, choose capacity modes, and back up your data.

Ad 728×90

What DynamoDB is — and how it differs

DynamoDB is a fully-managed key-value/document database that stays fast at any size. Unlike SQL, there are no joins and you cannot scan efficiently by arbitrary columns. Why: you design around how you'll READ the data, choosing keys so every important query hits a key directly. It scales to millions of requests with no servers to manage.

List your tables

aws dynamodb list-tables

Tables, items, and attributes

A table holds "items" (think rows), and each item is a bag of "attributes" (think fields) — but items in one table need not share the same attributes. Why flexible: you can store different entity types together. Items are addressed by a primary key, defined next.

The classic way to picture it:
  Table  -> Users
  Item   -> one user (a JSON-like record)
  Attribute -> userId, name, email, createdAt ...
Unlike SQL there is no fixed schema beyond the key attributes.

Primary keys — partition key and sort key

Every item is found by its primary key. Simple key = just a partition key (like a unique id). Composite key = partition key + sort key, which groups related items under one partition and sorts them. Why: a composite key lets you store, say, all orders for one customer together and query them as a range.

A table keyed by userId (partition) + createdAt (sort).

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

Writing and reading items

put-item writes (or replaces) one item; get-item fetches by full key; query fetches a range under one partition key. Why query over scan: query reads only the matching partition and is cheap; scan reads the whole table and gets slow and expensive as data grows.

Write an item

aws dynamodb put-item --table-name Orders --item '{

"userId":    {"S": "u-100"},

"createdAt": {"S": "2024-05-01T10:00:00Z"},

"total":     {"N": "42.50"},

"status":    {"S": "shipped"}

}'

Read all orders for one user (a query on the partition key)

aws dynamodb query --table-name Orders \
  --key-condition-expression "userId = :u" \
  --expression-attribute-values '{":u": {"S": "u-100"}}'

Secondary indexes — querying by other fields

You can only query by the table's key — unless you add an index. A Global Secondary Index (GSI) gives the table a second key layout, so you can query by a different attribute (e.g. by status instead of userId). Why: it is how DynamoDB supports more than one access pattern on the same data.

Add a GSI so you can query orders by status

aws dynamodb update-table --table-name Orders \
  --attribute-definitions AttributeName=status,AttributeType=S \
  --global-secondary-index-updates '[{

"Create": {

"IndexName": "by-status",

"KeySchema": [{"AttributeName":"status","KeyType":"HASH"}],

"Projection": {"ProjectionType":"ALL"}

}]'

Data modeling — single-table design

In DynamoDB the advanced pattern is to keep multiple entity types in ONE table, using key prefixes (USER#123, ORDER#456) so related records sit together and a single query returns them. Why: it minimizes round-trips and cost. It feels strange coming from SQL, but it is how high-scale DynamoDB apps are built.

aws dynamodb put-item --table-name AppData --item '{

"PK": {"S": "USER#u-100"},

"SK": {"S": "PROFILE"},

"name": {"S": "Alice"}

}'

One table, many entity types, distinguished by key prefixes:
  PK = "USER#u-100"   SK = "PROFILE"        -> the user's profile
  PK = "USER#u-100"   SK = "ORDER#2024-..." -> that user's orders
A single query on PK = "USER#u-100" returns the profile AND the orders.

Capacity modes — on-demand vs provisioned

Two ways to pay. On-demand (PAY_PER_REQUEST): pay per request, scales instantly, zero planning — best for spiky or unknown traffic. Provisioned: you set read/write capacity units; cheaper for steady, predictable load. Why: pick on-demand while learning or for bursty apps; switch to provisioned to save money once traffic is steady.

Switch a table to provisioned capacity with set throughput

aws dynamodb update-table --table-name Orders \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

Streams — react to every change

A DynamoDB Stream is an ordered feed of every create/update/delete on a table. Why: hook a Lambda to it (see the Lambda lesson) to send a welcome email when a user is added, keep a search index in sync, or replicate data — all triggered automatically by writes.

Turn on a stream that emits both the old and new image of each item

aws dynamodb update-table --table-name Orders \
  --stream-specification \
  StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

Backups and DynamoDB Local

On-demand backups snapshot a table instantly with no performance hit; point-in-time recovery (PITR) lets you restore to any second in the last 35 days. DynamoDB Local is a downloadable version you run on your laptop. Why local: develop and test for free, offline, without touching real AWS tables.

Take an on-demand backup

aws dynamodb create-backup --table-name Orders \
  --backup-name orders-$(date +%F)

Enable continuous point-in-time recovery

aws dynamodb update-continuous-backups --table-name Orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

Run DynamoDB Local in Docker and point the CLI at it:
docker run -p 8000:8000 amazon/dynamodb-local
aws dynamodb list-tables --endpoint-url http://localhost:8000