Access pattern diagnosis
See which of your reads are cheap Queries vs expensive Scans, with one-click GSI suggestions.
For every entity Tablyne detects, it works out the reads that entity supports and labels each one a cheap Query or an expensive Scan — so you can see where a table fights its access patterns before it’s a production problem.
Why it matters
DynamoDB has two ways to read many items. A Query targets a single partition by its key and is fast and cheap. A Scan reads the whole table and filters in memory — it’s slow, costs read units proportional to table size, and gets worse as the table grows. A healthy design serves every important read as a Query. Spotting the reads that fall back to a Scan tells you exactly where a global secondary index is missing. For the underlying concept, see /learn/query-vs-scan/.
Where to find it
Access patterns appear in two places in the Studio:
- The Entities tab lists them per entity, full width, with a fix button on the Scan.
- The Map tab’s inspector shows them for the selected node.
The patterns Tablyne derives
From each entity’s keys and relationships, Tablyne enumerates:
| Pattern | Operation | Cost |
|---|---|---|
| Get the item | Query PK=… SK=… | 🟢 Query |
| Children by parent | Query PK=… SK begins_with TYPE# | 🟢 Query |
| By GSI (one per index) | Query GSI… PK=… | 🟢 Query |
| By a non-key attribute | Scan + filter attr = … | 🔴 Scan |
The “by parent” pattern only appears when the entity is the child side of an inferred item-collection (its sort-key prefix names a child type under a parent partition). The Scan pattern is generated for the first plain scalar (S/N) attribute that isn’t part of any key — the canonical “I need to look this up by a field that isn’t a key” case.
Orders of a User Query PK=USER#<id> SK begins_with ORDER# base 🟢 Query
Get Order Query PK=USER#<id> SK=ORDER#<id> base 🟢 Query
Order by status Scan + filter status = … base 🔴 Scan [suggest GSI]Query patterns are green and marked supported; the Scan pattern is red, outlined in magenta, and marked unsupported.
One-click GSI suggestion
Next to any Scan pattern is a suggest GSI button. It opens a read-only explainer describing the index that would convert that Scan into a Query:
- A proposed index name (
GSI_<attr>), - The attribute used as the new partition key,
ALLprojection (so the query returns full items),- A note that a backfill is needed because existing items don’t carry the new key yet.
The suggestion never changes anything on its own. From it, start migration hands off to the GSI migration wizard, pre-filled with the attribute and the entity scope, where you preview and execute the change deliberately.
Limitations to keep in mind
- Derived, not exhaustive: Tablyne enumerates the obvious patterns from your keys and one representative non-key Scan — it isn’t a complete catalog of every query your app issues.
- Sample-bound: which attributes (and therefore which Scan pattern) are surfaced depends on the loaded rows until you count all; see /docs/std-overview/.
- The cost label is structural: it reflects whether the operation pins a partition key, not measured CloudWatch latency or consumed capacity.