DynamoDB

In this lesson we cover Amazon DynamoDB — a fully managed, serverless NoSQL database from AWS designed for low-latency access, seamless scaling, and high availability. You’ll learn core concepts, data modeling patterns, indexing options, stream processing, cost-optimization choices, and common integrations.

DynamoDB is intended for high-traffic, rapidly changing workloads where predictable low-latency access and minimal operational overhead are required. Use it for user profiles, session stores, leaderboards, real-time analytics metadata, and other internet‑scale applications.

A presentation slide titled "Why do we need DynamoDB?" showing an Amazon DynamoDB icon and a NoSQL icon, plus five benefit icons labeled Managing and Scaling, Serverless, Handle High Traffic, Automatic Sharding, and Operations. The slide is © KodeKloud.

Why use DynamoDB?

Fully managed and serverless: no servers to provision or maintain.
Seamless scaling and automatic sharding for large data sets.
Low-latency single-digit millisecond reads/writes.
Durable and highly available with integrated backups, replication, and recovery options.

Because DynamoDB is a managed AWS service, AWS handles the underlying compute and storage resources, patching, fault tolerance, and capacity distribution so you can concentrate on application logic.

Core concepts

Table — the primary container for items.
Item — a single record (JSON-like document).
Attribute — a named field in an item (scalar or nested).

Component	Description	Example
`Table`	Container for items.	`People`, `Music`
`Item`	A record/document in the table.	`{ "PersonID": 101, "LastName": "Smith" }`
`Attribute`	Field within an item. Can be scalar or nested.	`Address`, `Genre`, `PromotionInfo`

Example: People table (schema-less items)

[
  {
    "PersonID": 101,
    "LastName": "Smith",
    "FirstName": "Fred",
    "Phone": "555-4321"
  },
  {
    "PersonID": 102,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
      "Street": "123 Main",
      "City": "Anytown",
      "State": "OH",
      "ZIPCode": 12345
    }
  }
]

Primary key design

Every DynamoDB table requires a primary key that uniquely identifies each item. Primary keys determine how data is partitioned and organized.

Key type	Structure	Uniqueness & behavior
`Partition key` (simple)	Single attribute	Unique across all items; hashed to determine physical partition
`Composite key`	Partition key + sort key	Items share the same partition key but must have unique partition+sort key combinations; items with the same partition key are stored together and ordered by sort key

For the People table above, PersonID is a good partition key. Avoid using non-unique attributes (e.g., FirstName) as a primary key. DynamoDB uses the partition key value as input to an internal hash function. When using a composite key, the partition key determines the physical partition while the sort key orders and scopes items within that partition.

Primary key selection is critical for performance and scalability. Choose partition keys that distribute traffic evenly (avoid “hot” partition keys) and use sort keys to model access patterns (ranges, time series, or aggregated grouping).

A diagram titled "DynamoDB – Composite Primary Key" showing a composite primary key broken into two attributes: the first attribute maps to the partition key and the second attribute maps to the sort key.

Example: Music table using a composite primary key The Music table uses Artist (partition key) + SongTitle (sort key). This lets you fetch all songs by an artist or filter songs within a title range.

[
  {
    "Artist": "No One You Know",
    "SongTitle": "My Dog Spot",
    "AlbumTitle": "Hey Now",
    "Price": 1.98,
    "Genre": "Country",
    "CriticRating": 8.4
  },
  {
    "Artist": "No One You Know",
    "SongTitle": "Somewhere Down The Road",
    "AlbumTitle": "Somewhat Famous",
    "Genre": "Country",
    "CriticRating": 8.4,
    "Year": 1984
  },
  {
    "Artist": "The Acme Band",
    "SongTitle": "Still in Love",
    "AlbumTitle": "The Buck Starts Here",
    "Price": 2.47,
    "Genre": "Rock",
    "PromotionInfo": {
      "RadioStationsPlaying": ["KHCR", "KQBX", "WTNR", "WJJH"],
      "TourDates": { "Seattle": "20150622", "Cleveland": "20150630" },
      "Rotation": "Heavy"
    }
  }
]

Query patterns enabled by a composite key:

Query all items with a specific Artist.
Query items for Artist with range filters on SongTitle (e.g., between “A” and “M”).

Secondary indexes

Secondary indexes let you query the table using different keys than the primary key, providing flexible access patterns.

Index type	Key behavior	When to use
Global Secondary Index (GSI)	Own partition key and optional sort key (can differ from base table)	Use when you need an alternate partition/sort combination for queries
Local Secondary Index (LSI)	Same partition key as base table, different sort key	Use when you need alternate sorting/querying within the same partition; must be created at table creation

Limits: up to 20 GSIs and 5 LSIs per table.

A diagram titled "Secondary Index" showing Amazon DynamoDB flowing into a Table and then an Index. The index branches to boxes for Global Secondary Index and Local Secondary Index with notes about partition/sort key differences and item limits.

Index example (GSI: GenreAlbumTitle) Suppose you need queries by Genre and AlbumTitle. Create a GSI named GenreAlbumTitle:

Genre = partition key for the index
AlbumTitle = sort key for the index

DynamoDB automatically projects key attributes from the base table to the index; you can choose to project additional attributes. The index stays in sync: updates, inserts, and deletes in the base table are reflected in the index. Example items as they appear in the GenreAlbumTitle index:

[
  {
    "Genre": "Country",
    "AlbumTitle": "Hey Now",
    "Artist": "No One You Know",
    "SongTitle": "My Dog Spot"
  },
  {
    "Genre": "Country",
    "AlbumTitle": "Somewhat Famous",
    "Artist": "No One You Know",
    "SongTitle": "Somewhere Down The Road"
  }
]

DynamoDB Streams

DynamoDB Streams capture data modification events (INSERT, MODIFY, REMOVE) and expose them as an ordered stream for up to 24 hours. Each stream record includes metadata and item image(s) depending on the event type. Typical stream record images:

INSERT — the entire new item image.
MODIFY — the before and after images of the changed item.
REMOVE — the entire item image before deletion.

A common architecture is to connect a DynamoDB Stream to an AWS Lambda function for near real-time processing (e.g., send welcome emails when a new customer item has an EmailAddress). INSERT example

{
  "CustomerID": 1034,
  "LastName": "Major",
  "FirstName": "Alice",
  "EmailAddress": "alice@example.com"
}

MODIFY example (before and after)

{
  "Before": {
    "CustomerID": 1034,
    "LastName": "Major",
    "FirstName": "Alice",
    "EmailAddress": "alice@example.com"
  },
  "After": {
    "CustomerID": 1034,
    "LastName": "Major",
    "FirstName": "Alice",
    "EmailAddress": "alice_new@example.com"
  }
}

REMOVE example

{
  "CustomerID": 1034,
  "LastName": "Major",
  "FirstName": "Alice",
  "EmailAddress": "alice@example.com"
}

Useful integrations for streams:

Trigger AWS Lambda functions for event-driven workflows.
Send events to Kinesis Data Streams for complex real-time processing.

Table classes and capacity modes

DynamoDB provides options to balance cost and performance.

Option	Purpose
`Standard` table class	Default; recommended for most workloads
`Standard-IA` table class	Lower storage cost for infrequently accessed tables (archives, logs)
On-demand capacity mode	Pay-per-request; ideal for unpredictable or spiky traffic
Provisioned capacity mode	Allocate read/write capacity units; use when traffic is predictable and you want finer control

All secondary indexes inherit the base table’s table class. You can change table class and capacity mode from the Console, CLI, or SDK.

Key features at a glance

Flexible data models: key-value and document.
Serverless operation and automatic partitioning.
On-demand and provisioned capacity modes.
Secondary indexes (GSI, LSI) for alternate query patterns.
On-demand backup & restore and point-in-time recovery.
Global tables for active-active multi‑Region workloads.
Integration with analytics and streaming services.

A presentation slide titled "DynamoDB – Features." It displays seven numbered feature cards with colorful icons, listing items like Key‑Value/Document Data Models, Serverless, Global Tables, Secondary Indexes, On‑Demand Backup & Restore, and Read/Write Capacity Modes.

Integrations and analytics

DynamoDB works with many AWS services to enable analytics, streaming, and monitoring:

Streams → AWS Lambda for event-driven processing. See: AWS Lambda
Export to Amazon S3 for archival and downstream analysis. See: Amazon S3
Use AWS Glue, Amazon Athena, or Amazon Redshift for analytics and ETL.
Monitor with Amazon CloudWatch and audit with AWS CloudTrail.
Stream to Amazon Kinesis Data Streams for real-time analytics.

A diagram of Amazon DynamoDB integrations: the left side shows the DynamoDB icon and a “Configure Key Features” list (NoSQL workbench, encryption at rest, on‑demand capacity, global tables, point‑in‑time recovery, PartiQL). The center/right show exporting/analyzing/streaming data to AWS services like Amazon S3, AWS Glue Elastic Views, Amazon Kinesis Data Streams, AWS CloudTrail, and Amazon CloudWatch.

Common use cases

Internet-scale user profiles, shopping carts, and metadata storage.
Real-time applications: gaming leaderboards, chat/message metadata, streaming metadata.
Session stores and caching with consistently low latency.
Event-driven architectures using Streams + Lambda for near-real-time workflows.

Summary

DynamoDB is a fully managed NoSQL database optimized for performance and scalability. Key takeaways:

Core entities are tables, items, and attributes.
Choose primary keys carefully: partition key or partition+sort key (composite).
Use GSIs and LSIs to support alternate query patterns.
DynamoDB Streams enable near real-time processing; stream records are retained for 24 hours.
Use table classes and capacity modes to optimize cost and performance for your workload.

Introduction

Services - Networking

Services - Storage

Services - Compute

Services - Database

Services - Application Integration

Services - Data and ML

Services - Migration and Transfer

Services - Management and Governance

Services - Security

Bringing it all together

Designing for Security

Designing for Reliability

Designing for Performance

Designing for Cost-Optimization

Applying your Design Skills

Core concepts

Primary key design

Secondary indexes

DynamoDB Streams

Table classes and capacity modes

Key features at a glance

Integrations and analytics

Common use cases

Summary

Links and references

Watch Video

​Core concepts

​Primary key design

​Secondary indexes

​DynamoDB Streams

​Table classes and capacity modes

​Key features at a glance

​Integrations and analytics

​Common use cases

​Summary

​Links and references

Watch Video

Core concepts

Primary key design

Secondary indexes

DynamoDB Streams

Table classes and capacity modes

Key features at a glance

Integrations and analytics

Common use cases

Summary

Links and references