In this chapter
We'll meet DynamoDB's own vocabulary — tables, items, attributes, partition keys, sort keys, composite keys — and see why choosing a partition key matters from the very first item.
The Problem in Real Life
GreenMart just shipped its first international orders — Dubai, then Singapore, with more cities lining up behind them. Somewhere between the second new market and the third, Sarah realizes she's been the person woken up at 3 a.m. when a database server falls over, for six months straight, and nobody actually signed up for that on purpose.
Mike finds her holding a torn, coffee-stained page covered in a hand-drawn diagram of every server GreenMart currently runs — boxes, arrows, red-pen notes about who's on call this weekend.
I didn't sign up to run servers. I signed up to run a store.
Sarah
A Cluster You Manage vs. A Table You Just Use
Managed means AWS runs the servers
Scaling, patching, failover — all handled underneath the table's name, without GreenMart operating a cluster.
Item and attribute, not document and field
Same flexible, schema-light shape as MongoDB — DynamoDB's own naming for the same idea.
The partition key routes every request
It decides which physical partition an item lives on — the single most consequential decision on the table.
Composite key = partition key + sort key
Together, the two values make an item unique — neither one alone has to be.
The DynamoDB Data Model
DynamoDB is Amazon's fully managed NoSQL database — "managed" meaning AWS itself runs the actual machines: scaling them, patching them, replacing a failed one, all without GreenMart ever being paged about it. Sarah doesn't provision a cluster. She creates a table, and AWS handles everything underneath that name from then on.
The vocabulary shifts slightly from MongoDB's, even though the underlying idea — flexible, schema-light records — is the same one this course already knows well. What MongoDB calls a document, DynamoDB calls an item. What MongoDB calls a field, DynamoDB calls an attribute. Same shape, same flexibility, different product's own naming.
No column list, no schema declared up front for anything beyond the two keys — the same flexibility GreenMart already relies on. What's new here is that DynamoDB asks for those two keys immediately, at table-creation time, not as an afterthought.
CreateTable("Orders", { partitionKey: "customerId", sortKey: "orderId" })PutItem("Orders", { customerId: "mike01", orderId: "ord-1", item: "Organic Apples", total: 12.5 })GetItem("Orders", { customerId: "mike01", orderId: "ord-1" })
Every DynamoDB table needs a partition key, and it's the single most consequential decision on the table: it's the value that decides which physical partition an item actually lives on. Every read and write is routed by it. There's no separate "add sharding later" step the way earlier Acts in this course sometimes had — DynamoDB is partitioned by design, from the very first item.
A sort key is optional, but when a table has one, every item sharing the same partition key gets ordered by it — here, every order belonging to mike01 sorts by orderId. Partition key plus sort key together form a composite key: the two values, taken together, are what actually make an item unique. Two items can share a partition key (many orders, one customer) or share a sort key value across different partitions (an orderId of "ord-1" could exist for a different customer too) — it's the combination DynamoDB requires to be unique, not either one alone.
Key Takeaway
A partition key isn't just an id. It's the routing decision for where an item physically lives — DynamoDB is partitioned from the first item, not sharded later as an afterthought.
Why This Matters
Every remaining chapter in this Act comes back to this one decision. Which field becomes the partition key shapes which questions GreenMart can ask cheaply and which ones become expensive — that's exactly where the next chapter goes.
GreenMart's first DynamoDB table exists, with real items in it, and nobody had to provision a server to make that true. The partition key Sarah picked wasn't a small decision, though — the next chapter is about exactly how much that one choice actually controls.