DynamoDB: Data modeling

In the previous lesson, you learned how primary keys shape data retrieval in DynamoDB and why Query is the preferred targeted access method over Scan. That foundation now leads to a critical shift in thinking: DynamoDB schema design begins with access patterns, not with entities and normalization. Relational database designers normalize tables first and write queries afterward, but DynamoDB inverts this sequence entirely. Every known access pattern must be documented before the table is created because the key structure you choose determines which queries are efficient and which are impossible.

This lesson explains the patterns that make single-table design practical for high-volume DynamoDB workloads. You will examine item collections grouped by partition key, the adjacency list pattern for many-to-many relationships, sparse indexes that index only relevant items and reduce write and storage overhead, time-series key strategies that reduce the risk of hot partitions, and a multi-tenant composite key design that supports tenant-level access patterns while distributing writes across partitions.

The following diagram illustrates how multiple entity types coexist in a single DynamoDB table and how a single Query retrieves an entire item collection:

Item collections and adjacency patterns

Efficient retrieval in DynamoDB depends on understanding how items are physically grouped and how relationships between entities are encoded directly into the key structure.

How item collections drive retrieval efficiency

An item collection is the set of all items in a table or local secondary index that share the same partition key value. DynamoDB stores all items in a collection on the same physical partition, which means a single Query operation reads them in one sequential I/O pass. ...