designing-dynamodb-tables

Single-table design co-locates related data using composite primary keys (partition and sort keys) and global secondary indexes to serve multiple access patterns efficiently. Define your access patterns first, then structure partition and sort keys to satisfy queries without table scans, minimizing cost and latency.

Access patterns are the specific queries your application needs to run—like fetching a user's posts or all comments on a post. DynamoDB schema design must anticipate these patterns upfront and create primary and secondary indexes that satisfy them directly, avoiding expensive full-table scans.

Yes. Single-table design stores users, posts, comments, and other entities in one table using entity-type prefixes in the sort key or a type attribute. This approach co-locates related data, reduces the number of tables, and improves query performance for hierarchical and one-to-many relationships.

Use composite keys where the partition key identifies the parent entity (user ID) and the sort key differentiates children (e.g., 'POST#timestamp'). This groups all a user's posts together, enabling efficient range queries. Global secondary indexes can reverse the relationship if needed.

Primary keys (partition and sort) define the main access path and determine table partitioning. Global secondary indexes create alternative key structures to support different queries—like retrieving posts by date when the primary key is user-centric. Each GSI incurs separate storage and write throughput costs.

Single-table design suits applications with well-defined, limited access patterns and hierarchical data. Avoid it if your queries are highly unpredictable, require frequent full-table scans, or span disconnected entity types. Multiple tables may be simpler for loosely related data.