NoSQL Data Modeling: Think Access Patterns First

Key Insights

• Model for queries, not for entity relationships — denormalization is expected
• Single-table design in DynamoDB reduces read costs by co-locating related items
• Document databases embed related data to avoid joins, trading write complexity for read speed

Query-First Design

In relational databases, you normalize first and query later. In NoSQL, start with your access patterns:

1. List all queries your application needs
2. Design partition keys and sort keys to serve those queries
3. Denormalize to avoid cross-partition lookups

Embedding vs Referencing

// Embedded (read-optimized): order with items
{
  "orderId": "123",
  "items": [
    {"product": "Widget", "qty": 2, "price": 9.99},
    {"product": "Gadget", "qty": 1, "price": 24.99}
  ]
}

// Referenced (write-optimized): separate collections
{"orderId": "123", "itemIds": ["item-1", "item-2"]}

When Denormalization Hurts

If the same data updates frequently and exists in many places, denormalization creates consistency challenges. Use references for frequently-updated shared data.