AWS DynamoDB (NoSQL Database)
AWS DynamoDB is a fully managed NoSQL database service that delivers single-digit millisecond performance at any scale. It stores data as items in tables — not in rows and columns like relational databases. DynamoDB is serverless, meaning no servers need to be provisioned, patched, or managed. AWS handles everything automatically.
What Is a NoSQL Database?
A NoSQL database does not enforce a fixed schema. Each item in a DynamoDB table can have different attributes. There is no need to define all columns upfront like in MySQL or PostgreSQL.
Analogy: A relational database is like a printed form — every field is fixed, and all entries must follow the exact same structure. A NoSQL database is like a sticky note — each note can have any content, any shape, any size.
DynamoDB Core Concepts
Table
A table is the top-level container in DynamoDB — similar to a table in SQL databases. A DynamoDB account can have any number of tables.
Item
An item is a single record in a table — similar to a row in SQL. Each item is a collection of attributes. Items in the same table do not need to have the same attributes (except the primary key).
Attribute
An attribute is a single data field within an item — similar to a column in SQL. An attribute has a name and a value. Supported types include String, Number, Boolean, List, Map, Binary, and Set.
Primary Key
Every item in DynamoDB must have a unique primary key. DynamoDB supports two types:
- Partition Key (Simple Primary Key): A single attribute that uniquely identifies each item. DynamoDB uses this value to determine which partition (physical storage location) stores the item.
- Partition Key + Sort Key (Composite Primary Key): Two attributes combined. Multiple items can share the same partition key as long as their sort keys differ. Items with the same partition key are stored together and sorted by sort key.
Table: Orders
Partition Key: CustomerId | Sort Key: OrderDate | Attributes: Item, Amount, Status
--------------------------+-------------------+----------------------------------
CUST-001 | 2024-03-01 | {item: "Laptop", amount: 75000}
CUST-001 | 2024-03-15 | {item: "Mouse", amount: 599}
CUST-002 | 2024-03-10 | {item: "Keyboard", amount: 1499}
CUST-003 | 2024-03-12 | {item: "Monitor", amount: 18000, warranty: "3yr"}
Notice that CUST-003's item has an extra attribute warranty that others do not — this is perfectly valid in DynamoDB.
DynamoDB Read and Write Operations
| Operation | Description |
|---|---|
| PutItem | Insert or replace an item (overwrites if same primary key exists) |
| GetItem | Retrieve a single item by its primary key (fastest operation) |
| UpdateItem | Modify specific attributes of an existing item |
| DeleteItem | Remove an item by its primary key |
| Query | Retrieve multiple items with the same partition key (fast) |
| Scan | Read every item in the table (slow and expensive — avoid for large tables) |
| BatchWriteItem | Write or delete up to 25 items in one API call |
| TransactWriteItems | All-or-nothing write across multiple items (like SQL transactions) |
DynamoDB Capacity Modes
On-Demand Mode
DynamoDB automatically scales to handle any request volume. Pay per request. No capacity planning required. Best for unpredictable or spiky workloads. Slightly more expensive per request than provisioned mode.
Provisioned Mode
A fixed number of read and write capacity units (RCUs/WCUs) is specified. Cost is lower than on-demand for predictable workloads. Auto Scaling can be enabled to automatically adjust capacity within defined limits based on actual usage.
- 1 RCU (Read Capacity Unit): Reads 1 item up to 4 KB per second (strongly consistent) or 2 per second (eventually consistent).
- 1 WCU (Write Capacity Unit): Writes 1 item up to 1 KB per second.
DynamoDB Indexes
Local Secondary Index (LSI)
An LSI uses the same partition key as the base table but a different sort key. It must be created when the table is created. Allows querying by a different sort attribute.
Global Secondary Index (GSI)
A GSI uses a completely different partition key and optional sort key — different from the base table. It can be added to an existing table. GSIs allow querying data in ways the original primary key structure does not support.
Base Table: Orders Partition Key: CustomerId | Sort Key: OrderDate Query: "Get all orders for CUST-001" ← works directly GSI: OrdersByStatus Partition Key: Status | Sort Key: OrderDate Query: "Get all PENDING orders sorted by date" ← needs GSI
DynamoDB Streams
DynamoDB Streams captures a time-ordered sequence of every change (insert, update, delete) made to items in a table. Streams retain records for 24 hours. Lambda functions can be triggered by stream events to react to database changes in real time.
[Item updated in DynamoDB]
|
[DynamoDB Stream captures change]
|
[Lambda triggered with change record]
|
[Send push notification] or [Update search index] or [Replicate to another table]
DynamoDB TTL (Time To Live)
TTL allows setting an expiry timestamp on individual items. When the timestamp expires, DynamoDB automatically deletes the item — at no extra cost. This is ideal for session data, temporary caches, or log entries that should not persist indefinitely.
Example: A session token item has a TTL attribute set to a Unix timestamp 24 hours in the future. After 24 hours, DynamoDB silently removes it.
DynamoDB Accelerator (DAX)
DAX is an in-memory caching layer for DynamoDB. It sits between the application and DynamoDB and caches frequently read items. DynamoDB reads take single-digit milliseconds. DAX reduces read latency to microseconds — up to 10x faster — for read-heavy workloads.
[Application]
|
[DAX Cache] ← hit? return in microseconds
|
miss? fetch from:
|
[DynamoDB Table] ← single-digit milliseconds
DynamoDB vs RDS — When to Use Which
| Factor | DynamoDB | RDS (MySQL/PostgreSQL) |
|---|---|---|
| Data structure | Flexible schema, key-value or document | Fixed schema, relational tables |
| Scale | Massive scale, horizontal scaling | Vertical scaling (bigger server) |
| Queries | Simple key-based queries, limited joins | Complex SQL, multiple joins |
| Transactions | Limited transactions (single table preferred) | Full ACID transactions |
| Latency | Single-digit milliseconds at any scale | Varies with query complexity |
| Best for | Gaming, IoT, sessions, shopping carts, real-time apps | Reporting, ERP, financial systems with complex relationships |
Real-World Example — Gaming Leaderboard
A mobile game needs a global leaderboard updated in real time with millions of players:
- Table: Leaderboard
- Partition Key: GameId | Sort Key: Score (number, descending)
- Each score update uses
UpdateItemto atomically increment the player's score. - A query by GameId sorted by score returns the top 100 players instantly.
- DAX caches the top leaderboard results — millions of reads per second without touching DynamoDB directly.
- TTL removes inactive player records after 90 days automatically.
Summary
- DynamoDB is a fully managed NoSQL database with single-digit millisecond performance at any scale.
- Data is organized in tables, items, and attributes. Primary keys (partition key or partition + sort key) uniquely identify items.
- On-Demand mode scales automatically. Provisioned mode offers lower cost for predictable workloads.
- GSIs allow flexible querying beyond the base table's primary key structure.
- DynamoDB Streams enable real-time event-driven processing. TTL automatically removes expired items. DAX provides microsecond caching.
