{"query":"single table design","locale":"en","total":122,"results":[{"title":"DynamoDB Single-Table Design: The Complete Guide","section":"","url":"https://dynotable.com/learn/dynamodb-single-table-design","kind":"guides","snippet":"Coming from SQL, the instinct is one table per entity: customers, orders, order_items. In DynamoDB that instinct is usually wrong. A single table that stores every entity, distinguished by overloaded key prefixes, lets you fetch a parent and its children in one Query — no joins, no N+1."},{"title":"DynamoDB Single-Table Design Tool","section":"","url":"https://dynotable.com/tools/dynamodb-single-table-design","kind":"page","snippet":"Turn entities and access patterns into a single-table key schema — PK/SK templates, an item-collection preview, GSI suggestions, and capacity cost hints."},{"title":"When NOT to Use Single-Table Design in DynamoDB","section":"","url":"https://dynotable.com/learn/dynamodb-when-not-single-table-design","kind":"guides","snippet":"Single-table design is the default advice for DynamoDB, and it earns it: one Query hands back a parent and its children, no joins, no N+1. But it is a trade — you buy read speed with a rigid, opaque schema. Some workloads can't afford that price, and forcing one table on them is its own footgun."},{"title":"DynamoDB Single-Table Design: The Complete Guide","section":"What is single-table design in DynamoDB?","url":"https://dynotable.com/learn/dynamodb-single-table-design#what-is-single-table-design-in-dynamodb","kind":"guides","snippet":"Single-table design stores every entity — customers, orders, order items — in one DynamoDB table, distinguished by overloaded partition key and sort key prefixes. Because the keys are designed around your access patterns rather than your entities, a parent and all its children live in one item collection and come back…"},{"title":"When NOT to Use Single-Table Design in DynamoDB","section":"When should you not use single-table design in DynamoDB?","url":"https://dynotable.com/learn/dynamodb-when-not-single-table-design#when-should-you-not-use-single-table-design-in-dynamodb","kind":"guides","snippet":"Avoid single-table design when your workload is heavy OLAP analytics, plain CRUD over a handful of unrelated entities, or entities that scale and fail independently. In those cases multiple tables read better, cost the same, and stay flexible. Single-table design only wins when access patterns are known, related, and…"}],"links":{"llmsTxt":"https://dynotable.com/llms.txt","sitemap":"https://dynotable.com/sitemap.xml","json":"https://dynotable.com/llms/json?query=","text":"https://dynotable.com/llms?query="}}