What Is DynamoDB?
DynamoDB is a fully managed NoSQL database that stores data as items (roughly analogous to rows) grouped into tables, where each item is identified by a primary key. Unlike RDS, there is no server to patch, no storage volume to resize, and no fixed schema beyond the key structure — attributes beyond the key can vary from item to item. DynamoDB is built for predictable, low-latency access patterns at massive scale: it distributes data across partitions automatically based on the partition key, and with on-demand capacity mode it scales throughput up and down without any capacity planning at all.
Cricket analogy: DynamoDB is like a scoreboard system that instantly looks up any player's stats by their exact registration number rather than scanning the entire tournament ledger — ask for Rohit Sharma's ID and you get the answer in milliseconds, no matter how many seasons of data exist.
Partition Keys, Sort Keys, and Access Patterns
Every DynamoDB table has a partition key that determines which physical partition an item lives on — DynamoDB hashes the partition key value to spread data and traffic evenly. Optionally, a table can also have a sort key, forming a composite primary key, which lets you store multiple related items under the same partition key and query them in sorted order (for example, all orders for one customer, sorted by order date). Because DynamoDB is schemaless and doesn't support arbitrary joins, you design your table around the specific queries your application needs to run — this is called single-table design, and it's the opposite of the normalize-first approach you'd take with RDS.
Cricket analogy: A partition key plus sort key is like organizing scorecards by team name (partition) and then by match date within that team (sort) — ask for all of Mumbai Indians' matches and you get them back already in chronological order, no shuffling needed.
Capacity Modes, Indexes, and Streams
DynamoDB offers two capacity modes: provisioned, where you specify read and write capacity units (and can attach auto-scaling policies), and on-demand, where you pay per request and DynamoDB scales instantly without configuration — ideal for unpredictable or spiky traffic. To query by attributes other than the primary key, you create Global Secondary Indexes (GSIs, which can use a different partition/sort key and have their own capacity) or Local Secondary Indexes (LSIs, which share the base table's partition key but use an alternate sort key, and must be created at table creation time). DynamoDB Streams captures a time-ordered log of item-level changes, which Lambda functions commonly consume to trigger downstream processing like updating a search index or sending a notification.
Cricket analogy: On-demand capacity mode is like a stadium instantly opening extra ticket counters when a surprise India-Pakistan clash sells out in minutes, rather than a ground staff manually predicting attendance weeks in advance and pre-allocating counters.
// Query all orders for one customer, newest first, using AWS SDK v3
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = DynamoDBDocumentClient.from(new DynamoDBClient({}));
const result = await client.send(new QueryCommand({
TableName: "Orders",
KeyConditionExpression: "customerId = :cid",
ExpressionAttributeValues: { ":cid": "CUST-4471" },
ScanIndexForward: false, // newest sort-key value first
Limit: 20,
}));
console.log(result.Items);A Scan operation reads every item in a table (or index) and filters afterward, making it far more expensive and slower than a Query, which uses the partition key to jump directly to the relevant items. Reaching for Scan as a default access pattern is a common beginner mistake that leads to throttling and high costs at scale — design your keys and indexes around Query up front.
- DynamoDB is a fully managed, schemaless NoSQL database with automatic horizontal scaling via partitioning.
- The partition key determines data distribution; an optional sort key enables ordered, related-item queries.
- Table design follows access-pattern-first (single-table) design rather than upfront normalization.
- On-demand capacity mode scales instantly with no capacity planning; provisioned mode uses configurable read/write units.
- Global Secondary Indexes allow querying by alternate keys; Local Secondary Indexes share the base partition key.
- DynamoDB Streams provides a change log commonly consumed by Lambda for event-driven processing.
- Prefer Query over Scan — Scan reads the whole table and is significantly more expensive at scale.
Practice what you learned
1. What determines which physical partition a DynamoDB item is stored on?
2. What is the main benefit of on-demand capacity mode over provisioned mode?
3. Which statement correctly distinguishes a Local Secondary Index (LSI) from a Global Secondary Index (GSI)?
4. Why should a Scan operation generally be avoided for frequently-run queries at scale?
5. What is DynamoDB Streams commonly used for?
Was this page helpful?
You May Also Like
RDS Fundamentals
Amazon RDS is a managed relational database service that automates provisioning, patching, backups, and failover for engines like MySQL, PostgreSQL, and Aurora.
IAM Policies Explained
IAM policies are JSON documents that define permissions, and understanding their structure and evaluation logic is essential to securing an AWS account.
AWS KMS Basics
AWS Key Management Service (KMS) creates and controls the cryptographic keys used to encrypt data across AWS services, without exposing the underlying key material.