DynamoDB Single-Table Design Tool
Enter your entities and how you need to read them — the planner suggests entity-prefixed PK/SK key templates, previews the item collections, and adds a GSI only where the base table can’t serve a pattern.
From access patterns to a key schema
Single-table design starts from the reads, not the entities: instead of normalizing tables and joining at query time, you list every way the application needs to fetch data — get a user by ID, list a user’s orders newest-first, find an account by email — and shape the keys so each one is a single GetItem or Query. Every pattern the base table can’t answer costs you an index, and that trade should be visible before you create the table.
This planner makes the trade explicit. It applies the standard single-table rules deterministically — entity-prefixed composite keys, item collections for one-to-many patterns, inverted or attribute-scoped GSIs for the rest — and where a pattern can’t be served cleanly it says so instead of pretending. The example-items table shows how the resulting rows actually sit next to each other inside a partition.
The output is a plain CreateTable JSON document with generic string-typed key attributes — nothing tool-specific to unpick later — plus cost hints that reuse the exact 4 KB read / 1 KB write rounding our pricing and item-size calculators use.
New to the concepts, or unsure the approach fits your workload? Our single-table design guide explains the idea from first principles, and when NOT to use it covers the honest counter-cases. Once the schema is set, compose the actual request in the DynamoDB Query Builder or estimate the full monthly bill with the DynamoDB Pricing Calculator.
Frequently asked questions
What is single-table design in DynamoDB?
A modeling approach where all of an application’s entity types share one table with generic partition and sort key attributes (PK/SK). Related items share a partition key so a single Query fetches them together — the design is driven by your access patterns rather than by normalized entity shapes.
How does this planner decide the key design?
With fixed, published rules — deterministic, not generative. Every entity starts as the root of its own item collection with entity-prefixed keys; the first list-children pattern moves the child into its parent’s partition on a composite sort key; lookups by other attributes, second parents, and list-everything patterns become GSI suggestions; and a pattern the rules can’t serve cleanly is marked as unsupported instead of receiving a made-up design.
When does an access pattern need a global secondary index?
When the base table’s key layout can’t answer it: fetching a re-homed child by its own ID, listing the same items under a second parent, finding an item by a non-key attribute such as an email, or listing every item of one type. Each of those re-keys the same data, which only an index can do — the planner suggests one per key shape and reuses it across patterns that share the shape.
How do GSIs affect DynamoDB cost?
Every GSI maintains its own projected copy of the items it covers, so each table write also consumes write capacity on every GSI that projects the item, and storage is billed per copy. The cost card shows a base-table estimate and one with GSI write replication included, using the same 4 KB read / 1 KB write rounding as our pricing and item-size calculators.
Does the planner upload my data model anywhere?
No. The page is static and the design is computed entirely in your browser — entity names, ID attributes, and access patterns never reach a server. The only way a design leaves the page is the “Copy link” URL, which packs it into the link so sharing stays a deliberate act.