TopolearnUnbounded and hot partitions are the most common cause of Cassandra performance incidents.
A partition lives on RF nodes and is read as a unit, so its size and traffic matter:
- too big: very large partitions (rule of thumb: keep them under about 100 MB and 100,000 rows, ideally much smaller) slow reads, compaction, repair and streaming,
- too hot: one partition key receiving a big share of traffic (a celebrity user, a global counter) overloads its replicas while the rest of the cluster idles.
Bucketing adds a component to the partition key to bound growth:
- time buckets:
((sensor_id, day), ts)instead of((sensor_id), ts); pick the bucket (hour, day, month) so a bucket holds a manageable amount at peak rate, - hash or shard buckets:
((channel_id, bucket), ts)withbucket = hash(msg_id) % 8spreads a hot key over 8 partitions; readers query all 8 and merge.
Bucketing costs reads: a query spanning a week of daily buckets issues 7 queries (run them concurrently).
Estimate before shipping: rows per partition = rate x bucket duration; size = rows x (bytes per row + overhead). Then verify with nodetool tablehistograms (partition size percentiles) and nodetool tablestats (maximum compacted partition size). Cassandra 5.0 can also warn or fail on oversized partitions with guardrails such as partition_size_warn_threshold.
Example
-- Unbounded: one partition per sensor grows forever
-- PRIMARY KEY ((sensor_id), ts)
-- Bounded: one partition per sensor per day
CREATE TABLE shop.readings_by_day (
sensor_id text, day date, ts timestamp, value double,
PRIMARY KEY ((sensor_id, day), ts)
) WITH CLUSTERING ORDER BY (ts DESC);
-- Estimate: 1 reading/s -> 86,400 rows/day x ~40 bytes = ~3.5 MB per partition: OK
-- A week of data = 7 partition reads, issued concurrently by the app
SELECT ts, value FROM shop.readings_by_day WHERE sensor_id = 's-17' AND day = '2026-10-17';
-- $ nodetool tablehistograms shop readings_by_day
-- Percentile Partition Size Cell Count ...
-- 99% 3.97 MiB 86400Remember
- Keep partitions bounded (well under ~100 MB) and traffic evenly spread
- Time buckets bound growth; hash buckets split hot keys
- Estimate rows and bytes per partition before launch
- Check nodetool tablehistograms and tablestats in production
Watch out for
- Partitioning event data only by user or device id, creating partitions that grow forever.