DynamoDB: NoSQL on AWS
By the end of this lesson, you'll be able to:
- Explain what a partition key is and why DynamoDB is organized around one
- Explain why designing around access patterns matters more, and earlier, in DynamoDB than in a relational database
- Identify DynamoDB as a fit for a described key-oriented workload
Prerequisites: "Amazon RDS: Managed Relational Databases"
Amazon DynamoDB, in one sentence
Amazon DynamoDB is AWS's managed NoSQL database service — a key-value and document-style database built for fast, predictable lookups by a known key, rather than the flexible, ad-hoc, relationship-based querying a relational database supports.
Tables, items, and the partition key
A DynamoDB table holds items (roughly comparable to a row, though each item's set of attributes can differ from the next). Every item is stored and retrieved through its partition key — the value DynamoDB uses to determine where and how an item is stored, and the value your application supplies to fetch it back quickly.
Items sharing the same partition key value are grouped together, which is exactly why the partition key you choose isn't a minor detail — it directly shapes how fast and predictable your application's actual lookups will be.
Design for access patterns first — this is the opposite order from relational
This is the single most important habit to build for DynamoDB, and it runs opposite to relational database instincts: design the table around how your application will actually look up data, before worrying about a "complete" or "normalized" data model. A relational schema can often be designed first and queried flexibly afterward, because SQL can join and filter across tables in ways decided later. DynamoDB does not offer that same flexibility after the fact — a partition key chosen without the real access pattern in mind can leave you unable to look up data efficiently, even though the data is sitting right there in the table.
Concretely: if an application's dominant need is "look up all orders for a given customer, fast," the partition key should be built around the customer, not around some other attribute the application never actually looks up by directly.
A fit example
A logging system ingesting a very high volume of independent events, where the dominant access pattern is "fetch all events for a specific device ID, fast," is a strong DynamoDB fit: a clear, known key to look up by, high write volume, and little need to query flexibly across unrelated attributes. Compare this to Karoo Retail's customer/order reporting from the previous lesson, which needed exactly the kind of cross-table, ad-hoc querying DynamoDB doesn't prioritize — a reminder that the right choice depends on the workload, not on one database being universally better.
Exercise
A device-monitoring application's dominant need is: "given a device ID, fetch all of its recent events quickly." Based on this lesson, what should the partition key be built around, and why would choosing a less relevant attribute as the partition key make that lookup harder later?
Show hint
The partition key should match the value the application will actually look up by most often — not an attribute that happens to be unique but isn't the real access pattern.
DynamoDB: NoSQL on AWS Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
Amazon DynamoDB is a managed NoSQL database built around fast, predictable lookups by a partition key rather than flexible ad-hoc queries across relationships, which means a DynamoDB table's design has to start from the application's actual access patterns rather than being decided independently of them.