Why DynamoDB Requires a Different Mindset
Think of a traditional SQL database like a well-organized filing cabinet: every document goes into a labeled folder, folders go into labeled drawers, and when you need something, you open multiple drawers and combine documents on your desk. DynamoDB is more like a warehouse with a barcode scanner — you design the shelves specifically for how you'll retrieve boxes, and retrieval is instant because everything is pre-positioned.
This analogy captures the core difference:
- SQL (Relational): Design the data model first using normalization (3rd Normal Form) to eliminate redundancy. Queries are figured out later using
JOINs across multiple tables. The schema is flexible to query patterns because the database engine handles the heavy lifting at query time. - DynamoDB (NoSQL): Design your access patterns first. The table structure is purpose-built to answer specific questions. There are no
JOINs — if you didn't pre-position your data correctly, you cannot retrieve it efficiently.
The "Access Pattern First" Mentality
In DynamoDB, you do not create separate tables for "Users," "Orders," and "Products." You create a single table for your Application and embed the relationships in the key structure.
Before writing a single line of code, you must enumerate every way your application will read and write data. A complete access pattern list looks like this:
| # | Access Pattern | Key Condition |
|---|---|---|
| 1 | Get user profile by ID | PK = USER#<id> AND SK = PROFILE |
| 2 | Get all orders for a user | PK = USER#<id> AND SK begins_with ORDER# |
| 3 | Get a specific order | PK = USER#<id> AND SK = ORDER#<id> |
| 4 | Get order by status | GSI query on STATUS#<value> |
If you skip this step, you will discover mid-development that your key structure cannot answer a critical query — and refactoring a DynamoDB table is painful because you cannot ALTER TABLE.
The cardinal rule: Every query in DynamoDB must start with an exact match on a Partition Key. If you cannot identify the Partition Key for a query, you need a Global Secondary Index (GSI) or a redesign.
Interviewers frequently ask: "How would you migrate a relational schema to DynamoDB?" The wrong answer is "create one table per entity." The correct answer is: "I would first enumerate all access patterns, then design a single-table schema where the key structure pre-joins related entities. I would only use multiple tables if the entities have completely disjoint access patterns or different TTL/stream requirements."