Introduction to DynamoDB
Explore Amazon DynamoDB's core architecture, data model, and key design principles. Understand how to choose partition and sort keys, implement access-pattern-first design, and optimize read operations with Query versus Scan. This lesson prepares you to design scalable, efficient, and cost-effective DynamoDB tables.
Amazon DynamoDB is AWS’s managed key-value and document database. Unlike relational databases running on Amazon RDS or Aurora, which commonly model data in tables and use joins across related tables, DynamoDB is a fully managed, serverless NoSQL database service designed for workloads that need consistent single-digit-millisecond latency at virtually any scale. AWS handles much of the infrastructure operation, including partition management, automatic replication across three Availability Zones in a region, underlying infrastructure maintenance, and regional high availability. Developers do not manage database servers, cluster endpoints, or the same-region replication topology. This operational model comes with an important trade-off: DynamoDB does not support relational joins, even though it offers SQL-compatible access through PartiQL, and it is not designed for relational-style transactions across normalized tables or efficient arbitrary-column filtering unless the access pattern is supported by a table key, local secondary index, or global secondary index. Instead, DynamoDB works best when access patterns are modeled before data is written.
DynamoDB offers two capacity modes. Provisioned mode lets teams specify exact read and write throughput units, which is cost-effective for predictable traffic. On-demand mode automatically scales to match request volume, trading a higher per-request price for zero capacity planning. Both modes expose the same API surface and the same latency characteristics, so the choice is purely an operational and cost decision.
Note: DynamoDB replicates every item across three Availability Zones within a region by default. You do not need to configure multi-AZ; it is built into the service at no additional charge.
The single most consequential design decision in DynamoDB is choosing the right primary key. That key governs how data is physically distributed across storage partitions, which queries can be served efficiently, and which queries become prohibitively expensive. Everything that follows in this lesson builds toward understanding why that decision matters so much.
Tables, items, and attributes
DynamoDB’s data model rests on three building blocks that map loosely, but not exactly, to relational concepts.
Table: A named collection of data, similar to a relational table, but without a fixed schema beyond the primary key definition.
Item: ...