View source on GitHub ↗

Amazon DynamoDB: The Warehouse Built Around Retrieval Lanes

DynamoDB organizes data around the questions an application must answer quickly and repeatedly.

The Business Goal

The company had chosen a new home for its hottest operational truth.

A warehouse.

Fast. Enormous. Ready for millions of products.

There was only one problem.

Nobody had decided where anything should go.

The Story

The warehouse organized itself

On opening morning, a truck arrived carrying the first shipment.

Wireless mice. USB-C docks. Keyboards. Headphones.

The warehouse manager, Noah, gave the crew a simple instruction:

“Put similar things together.”

It sounded sensible.

Mice went to the mouse aisle. Docks went to the dock aisle. Headphones went to the headphone aisle.

The shelves were neat.

The inventory team admired its work.

Then Maya called from one of her stores.

“A customer is holding wireless mouse P100. Which warehouses still have it?”

A worker walked to the mouse aisle.

He found P100.

Then he opened three warehouse ledgers and assembled the answer.

“San Jose has 120. Reno has 75.”

Maya was pleased.

The first question worked.

The questions begin to repeat

Ten seconds later, another store called.

“Which warehouses still have P100?”

Then another.

“How many P100s are in San Jose?”

Then a repair center called.

“Where is physical unit SN-98471?”

The promotion began.

The same questions arrived hundreds of times.

Then thousands.

No one was asking the warehouse to improvise.

They were asking a small set of known questions again and again:

Find one item by serial number.

Find one product in one warehouse.

Find every warehouse carrying one product.

Find every order belonging to one customer.

The shelves were tidy.

The retrieval path was not.

The dispatcher draws the lanes

The architect watched workers cross the building, open ledgers, combine facts, and return to the counter.

She took a piece of chalk and drew a line across the floor.

At the start of the line, she wrote:

SERIAL#SN-98471

At the end, she placed the item record.

Then she drew another lane:

PRODUCT#P100
        |
        +--> WAREHOUSE#W1
        +--> WAREHOUSE#W2

Then another:

CUSTOMER#C4821
        |
        +--> ORDER#2026-07-26#O900
        +--> ORDER#2026-07-21#O844

Every common question received an address.

Every address led to an answer.

The workers stopped searching the whole warehouse.

They started following retrieval lanes.

In this warehouse, you do not decide where an item belongs until you know how someone will ask for it.

That is the doorway into Amazon DynamoDB.

The Wrong Way

The wrong way to understand DynamoDB is:

“It is a relational database, except faster.”

It is not.

A relational model often begins by separating facts and preserving their relationships:

Products
Warehouses
Inventory
Customers
Orders

When someone asks a new question, SQL can join, filter, group, and sort those facts.

That flexibility is a strength.

A DynamoDB design begins elsewhere:

What exact requests must be fast?
Which requests are hottest?
What key can lead directly to each answer?
How will traffic spread across those keys?

The mistake is not choosing a relational database.

The mistake is choosing DynamoDB while still designing as if flexible joins will rescue missing access paths later.

Meet Amazon DynamoDB

Amazon DynamoDB is a serverless, fully managed, distributed NoSQL database supporting key-value and document data models.

Core idea: The application chooses keys that turn known questions into deliberate retrieval paths.

DynamoDB manages much of the distributed machinery:

The team still owns the decisions that give the warehouse its shape:

DynamoDB removes server administration.

It does not remove database design.

How the Retrieval Lanes Work

The warehouse

Table

A DynamoDB table is a named collection of items.

It does not need to represent only one entity type.

Warehouse table
    |
    +--> inventory records
    +--> physical item records
    +--> customer order records

One table can hold different item shapes when they serve related access patterns. Multiple-table designs are also valid.

The question is not:

“How advanced can we make one table?”

The question is:

“Can the model remain correct, understandable, and efficient?”

The package

Item

An item is one record.

{
  "PK": "PRODUCT#P100",
  "SK": "WAREHOUSE#W1",
  "Type": "Inventory",
  "ProductName": "Wireless Mouse",
  "WarehouseName": "San Jose",
  "Quantity": 120
}

Items in the same table can have different non-key attributes.

The writing on the package

Attribute

Attributes describe an item:

ProductName
WarehouseName
Quantity
Status

But writing WarehouseName on a package does not build a retrieval lane by warehouse.

An attribute describes an item. A key or index creates a route to it.

The main aisle

Partition key

The partition key is part of an item’s primary key.

The application supplies its value. DynamoDB uses that value as input to an internal hash function that determines the physical storage partition.

PRODUCT#P100
      |
      v
internal hash
      |
      v
physical storage managed by DynamoDB

The application chooses the routing label.

DynamoDB manages the physical destination.

The shelf position

Sort key

A composite primary key also includes a sort key.

Items with the same partition-key value can be grouped and ordered by their sort-key values:

PK = PRODUCT#P100

SK = WAREHOUSE#W1
SK = WAREHOUSE#W2
SK = WAREHOUSE#W3

That shape supports:

Get P100 in W1.

Get every warehouse carrying P100.

The combination of partition key and sort key uniquely identifies an item.

The retrieval ticket

GetItem and Query

When the application knows the full primary key, it can request one item:

GetItem
PK = PRODUCT#P100
SK = WAREHOUSE#W1

When it knows the partition key and wants a related group, it can query:

Query
PK = PRODUCT#P100

A Query requires equality on the partition key. It can also narrow results using conditions on the sort key.

The worker follows a lane designed in advance.

Scan

Then someone asked:

“Show me every low-stock product.”

No lane had been designed for that question.

A worker picked up a clipboard and began inspecting the warehouse.

Scan broadly
      |
      v
read items
      |
      v
apply filter
      |
      v
return matches

A filter can reduce what comes back to the application.

It does not prevent DynamoDB from reading the examined items first.

Query follows the address. Scan inspects the warehouse.

Scans are not forbidden. They can be appropriate for bounded administrative work, exports, backfills, or deliberately broad processing.

They are usually a warning sign when they sit on a hot application path.

Packing the Answer Ahead of Time

Maya called again.

“How many P100s are in San Jose—and what is the product called?”

The old records room would keep the product name in one place and inventory in another, then combine them when asked.

The new warehouse placed the information needed by the hot request together:

PK SK ProductName WarehouseName Quantity
PRODUCT#P100 WAREHOUSE#W1 Wireless Mouse San Jose 120
PRODUCT#P100 WAREHOUSE#W2 Wireless Mouse Reno 75

Wireless Mouse now appeared more than once.

The owner winced.

“We duplicated the truth.”

“We duplicated a fact,” the architect said. “Now we must decide which copy owns it and how the others change.”

Denormalization can make reads direct.

It also moves work toward writes:

Normalized design
store once -> combine later

Denormalized design
prepare copies -> read directly

This is not free speed.

It is a trade.

Architectural Mapping

Application request
        |
        v
Known partition key
        |
        +--> exact sort key -> one item
        |
        +--> sort-key condition -> related items
        |
        v
Ready-to-use result

The data model is successful when the application’s important requests map cleanly to keys and when those keys distribute traffic safely.

The model is incomplete when an important request has no route, a single key absorbs too much traffic, or duplicated facts have no ownership and update plan.

When to Use It

DynamoDB is a strong candidate when:

When Not to Use It

Consider another approach when:

Painkiller

Problem: A large application asks the same operational questions millions of times.
Pain: Reconstructing every answer through flexible relational work or broad searches can add coordination and operational pressure the hot path does not need.
AWS solution: DynamoDB lets the application organize items behind deliberate keys so known reads and writes follow scalable retrieval paths.

Knife Cut

Relational design asks how facts relate. DynamoDB design asks how the application will retrieve them. Neither question makes the other database obsolete.

The Warehouse Floor

What Actually Just Happened

In the story In DynamoDB What it actually means
Warehouse Table A collection of items
Package Item One record
Writing on a package Attribute A value that describes the item
Main aisle label Partition key A routing value used in the primary key
Shelf position Sort key The ordered second component of a composite primary key
Retrieval ticket GetItem or Query A targeted read through a known key
Clipboard search Scan A broad read across a table or index
Packing the answer early Denormalization Duplicating selected facts to support direct reads

The warehouse did not become fast because it held fewer facts.

It became direct because every important question had a route.

A Note From the Author

The warehouse makes DynamoDB look physically simple.

The real service is distributed. DynamoDB chooses and manages physical storage partitions; the application does not assign an item to a particular server.

Good key design also requires more than readable labels. Teams must consider traffic distribution, item size, consistency, quotas, indexes, retries, permissions, backups, recovery, and cost.

Single-table design is a technique, not a badge of sophistication. Use it when it makes related access patterns efficient and the model remains maintainable.

The analogy also makes denormalization look like copying a label. In production, duplicated facts need explicit ownership, update behavior, and failure handling.

Technical references:

The Last Bite

DynamoDB does not begin with the shelves.

It begins with the question at the door.

Design the route.

Then place the truth where that route can reach it.

Next chapter: Amazon DynamoDB: Keys, Access Patterns, and the Retrieval Map

The warehouse has learned to build around known questions.

Now Maya arrives with six requests—and one of them has no lane.