Multi-table versus single-table design

Given DynamoDB’s lack of support for runtime joins (which is by design, by the way), a common but potentially naive design choice for those new to NoSQL might involve normalizing data across multiple DynamoDB tables akin to relational databases. The intention might be to perform joins at runtime in the application layer. While DynamoDB could still maintain performance in this scenario, the application may spend more time engaging in input/output (I/O) round trips with the DynamoDB service than executing meaningful business logic.

Denormalization and occasional data duplication across items offer a strategy to circumvent the need for runtime joins, even at the application layer. Conversely, adopting a single table for all data without a clear requirement or data access pattern that requires all data together could introduce unnecessary complexity in development and troubleshooting, and may, in general, do more harm than good.

In the...