🗃️Single Table Design

NEW

Also known as: Denormalized Design, NoSQL Pattern

A NoSQL modeling pattern that stores multiple entity types in a single table, using key design and indexes to serve diverse access patterns.

DESCRIPTION

Single-table design is common in DynamoDB and other NoSQL systems to optimize for known access patterns. Instead of one table per entity, all entities share a single table with composite primary keys and secondary indexes. This approach reduces joins and minimizes request round-trips by co-locating related items. Denormalization, item collections, and careful key naming enable efficient queries. While it yields performance and cost benefits at scale, it increases modeling complexity and requires upfront access-pattern analysis. Migration and refactoring can be challenging if patterns change. Strong governance around item schemas and versioning helps maintain consistency.

ALTERNATIVE DEFINITIONS

AWS Prescriptive Guidance

Single-table design is a data modeling approach in which multiple entity types are stored in a single DynamoDB table.

Defines the approach in DynamoDB’s context with emphasis on multiple entities in one table.

Source

Alex DeBrie

Single-table design in DynamoDB means that you keep all your data in a single table and use generic primary keys and secondary indexes to model complex relationships.

Highlights composite keys and indexes for relationship modeling.

Source

RELATED TERMS

Amazon DynamoDB NoSQL Denormalization Composite Key Global Secondary Index Shard Key Item Collection Access Patterns Schema-less Query Patterns

COMPETING TERMS

Multi-Table Design Relational Normalization

KNOWLEDGE AREAS

Data Modeling Data Storage & Operations Data Engineering Cloud

TARGET AUDIENCE

Data Engineer Data Architect Cloud Architect Software Developer

EXTERNAL SOURCES

• Wikipedia - Amazon DynamoDB
• AWS - Best practices for NoSQL data modeling
• AWS Prescriptive Guidance - Single-table design overview and patterns
• AWS Serverless Land - Patterns catalog for DynamoDB usage

TOP QUESTIONS

Why use Single Table Design in DynamoDB?

It reduces join-like operations, improves query performance, and optimizes costs by aligning storage with access patterns.

Category: Relevancy

What is the biggest challenge with Single Table Design?

Upfront modeling complexity. You must understand access patterns early and design keys and indexes accordingly.

Category: Requirements

How do Global Secondary Indexes support Single Table Design?

GSIs provide alternative query paths, enabling efficient lookups for different access patterns without duplicating tables.

Category: Example

What are common mistakes in Single Table Design?

Treating NoSQL like relational databases, overusing scans, or ignoring item collection locality hurts performance and costs.

Category: Mistakes

How does Single Table Design impact data normalization?

It favors denormalization to minimize cross-item queries. Redundant attributes can speed reads at the cost of write complexity.

Category: Opinion

Is Single Table Design suitable for all workloads?

No. If access patterns are unknown or highly variable, a more flexible approach or multi-table design may be safer initially.

Category: Risks

How does Single Table Design handle relationships?

Use composite keys and item collections to co-locate related entities, and GSIs to query one-to-many or many-to-many relationships.

Category: Example

Can Single Table Design evolve over time?

Yes, but changes can be costly. Use versioned item schemas and carefully plan new indexes before migration.

Category: Requirements

What tools help with Single Table Design?

Modeling guides, DynamoDB Workbench, and community libraries can visualize access patterns and suggest key structures.

Category: Example