Single-Table Design Studio
Reverse-engineer and understand any DynamoDB table: entities, relationships, access patterns and partition health, from your real data.
Tablyne’s Single-Table Design Studio reads the items already in your table and reconstructs the model behind them — the entity types, how they relate, which reads are cheap, and where the design is likely to hurt at scale.
What it’s for
Single-table design packs many entity types (users, orders, payments…) into one DynamoDB table by overloading the partition and sort keys with TYPE#id conventions. That’s powerful but opaque: a raw pk/sk grid tells you nothing about what lives in the table. The Studio infers the design from the data itself, so you can understand an inherited table, document your own, or sanity-check a model before it ships.
Everything in the Studio is derived from your real items — there is no separate schema to maintain and nothing to configure. It works whether the table is a genuine single-table design or a plain one-object-per-row table; in the latter case it simply shows a single entity.
The four views
The Studio lives in the data screen’s view tabs, alongside Data and Structure:
| Tab | View | Doc |
|---|---|---|
| ◆ Entities | Detected entity types, schema and access patterns | /docs/entities/ |
| ◇ Map | Interactive ER diagram of entities, relationships and GSIs | /docs/entity-map/ |
| 🔥 Health | Hot-partition and key-skew prediction with a health score | /docs/partition-health/ |
The Entities tab also surfaces an access-pattern diagnosis — which of your reads are Queries versus Scans — and the GSI migration wizard (/docs/gsi-migration/) that turns an expensive Scan into a cheap Query. A fourth lens, the entity-grouped Data view (◧ in the Data tab toolbar), shows the same rows grouped under color-coded entity headers without leaving the grid.
Sample vs. full scan
By default the Studio infers the model from the rows currently loaded in the grid (the page you fetched, or whatever streaming pulled in). That keeps it instant and costs nothing extra, but it’s a sample: rare entity types deep in the table can be missed and counts are sample counts, not table totals.
Each Studio view shows a scan bar at the top. Click count all (the opt-in full scan) to read the entire table, re-infer the model, and replace sample counts with real ones:
Sample → fast, free, may miss rare entities, counts are partial
Count all → scans the whole table, exact counts, costs read unitsThe full scan paginates 1,000 items at a time and stops at a hard cap of 200,000 items so a very large table can’t hang the UI. Use reset to drop back to the sample. Because a full scan reads every item, it consumes read capacity — see /docs/capacity/ for what that costs.
How detection works (and its limits)
Detection leans on the standard single-table convention: the sort-key prefix before the first # usually names the entity type (ORDER#9001 → ORDER, PROFILE → PROFILE), falling back to the partition-key prefix. Designs that carry an explicit discriminator attribute instead (__typename, entityType, recordType, and similar) are also recognised.
Honest caveats:
- Convention-dependent. Tables that don’t use
TYPE#prefixes or a known discriminator attribute will be read as a single entity — that’s correct for plain tables, but means a non-standard single-table design may not shred cleanly. - A safety net collapses the result to one entity if the inferred “types” are nearly as numerous as the items themselves, so an id-keyed table never explodes into one entity per row.
- Byte sizes are approximate. Item sizes used for capacity and partition math are estimated from the JSON length of each item, not DynamoDB’s exact on-the-wire encoding.
- Sample-bound by default. Until you count all, schema coverage, relationships and health findings reflect only the loaded rows.
A typical workflow
- Open a table and load some rows (a scan, a query, or streaming).
- Switch to Entities to see what types live in the table and how each is shaped.
- Open Map to see the item-collection and GSI-overload relationships as a diagram.
- Run count all to get exact counts and catch rare entities.
- Check Health for hot-partition and skew risk, and act on any finding — often with a one-click GSI suggestion.