Partition health
Predict hot partitions, key skew, low cardinality, sequential keys and GSI skew before they hurt, with a design-health score.
The Health tab analyses how your items spread across partition keys and predicts the problems that bite at scale — hot partitions, key skew, the 10 GB partition limit — entirely from your data, with no CloudWatch metrics or runtime traffic required.
Offline and proactive
DynamoDB’s classic failures are about distribution: too many items or bytes funneled onto one partition key. Most tools only surface this after it hurts, via CloudWatch under live load. Tablyne predicts it by design, before there’s traffic, by grouping your loaded items by partition key and measuring the spread. The score and findings are computed offline from the sample (or the full table after count all).
The health score
The view leads with a 0–100 score. Every finding subtracts points by severity (a warning costs less than a critical), so a clean design scores 100 and a badly skewed one drops fast. Beside it sits a one-line summary: distinct partition keys, total items, and total estimated bytes.
The findings
Tablyne checks five risk patterns and reports each with a severity, a plain-language explanation, and a suggested fix:
| Finding | What it detects | Fix it suggests |
|---|---|---|
| Size limit | A partition’s bytes approaching DynamoDB’s 10 GiB item-collection hard limit (warn ≥50%, critical ≥80%) | Split the partition key |
| Skew | One partition holding far more items than the median — a “celebrity” key (warn ≥3×, critical ≥10×) | Shard the key |
| Low cardinality | The partition key barely spreads — too few distinct values or a huge average items-per-partition | Add a dimension to the key |
| Sequential key | Partition ids that look like dates or running numbers, funneling writes onto the “latest” partition | Shard / randomize the key |
| GSI skew | An overloaded GSI partition value dominating the index (warn ≥50%, critical ≥80% of index items) | Distribute via a better GSI key |
Findings are sorted worst-first. The GSI skew finding includes a distribute button that opens the GSI migration wizard pre-set to the offending key attribute.
Health 72
⚠ Skew partition USER#42 holds 11× the median (1,540 items)
↳ Shard the key
🔥 GSI skew GSI_status: STATUS#OPEN holds 86% of the index
↳ Distribute via a better GSI key [distribute]Partition heat map
The right panel ranks the busiest partitions (up to the top dozen) as a heat bar — item count and estimated bytes per partition — with the sample median noted at the bottom. It’s a quick visual of where your data piles up.
Honest caveats
Partition health is a prediction from a sample, not a guarantee:
- Sample-bound by default. Findings reflect only the loaded rows until you run count all to analyse the whole table; see /docs/std-overview/. A skew or size problem that lives entirely in unloaded items won’t show until then.
- Byte estimates are approximate. Per-item size is estimated from JSON length, not DynamoDB’s exact on-the-wire encoding — so the 10 GiB size-limit finding is a heads-up, not a precise measurement.
- Thresholds are heuristics. The ratios and cutoffs above are conservative rules of thumb tuned to catch real problems early; some flagged designs may be intentional for your workload.
- No live metrics. This is design-time analysis. It complements, not replaces, CloudWatch throttle and consumed-capacity monitoring under real traffic.