Kafka Disk and Retention Calculator
The disk a topic needs, and the retention.bytes
to set for it. Both figures are given, because the setting is per partition
and the intention almost never is.
kafka-disk-sizing.txt
updates as you type Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Reading retention.bytes as a topic limit
It is per partition. A topic with 12 partitions and retention.bytes of 1 GB holds up to 12 GB per replica.
Instead:Multiply by partitions, then by the replication factor.
Sizing disks to the retention figure
Compaction, segment rolling and a broker being down all need headroom, and a full disk takes the broker offline hard.
Instead:Leave substantial free space. Kafka does not degrade gracefully on a full disk.
Ignoring compression when estimating
Retention limits apply to the stored, compressed bytes, so the number of records held depends on how well the data compresses.
Instead:Measure the ratio on real data rather than assuming.
Where Kafka disk actually goes
Four multiplications and two traps. The multiplications are obvious and the traps are what make the estimate wrong by a factor rather than a percentage.
Replication multiplies everything
replication.factor=3 means three full copies of every byte, and it is the first thing forgotten when somebody sizes a cluster from a throughput figure. It multiplies disk directly and it multiplies inter-broker network traffic by the factor minus one, which is a separate cost covered by the cluster sizing calculator on this site.
retention.bytes is per partition
This is one word in the Kafka documentation and it is worth more than any other sentence here. The setting is a per-partition budget, so the topic holds it multiplied by the partition count, and the cluster holds that multiplied by the replication factor. A 100 GB intention on a 50 partition topic at replication factor 3 becomes 15 TB of disk. Both retention.ms and retention.bytes apply, and whichever is reached first wins.
A segment is only deleted once it is closed
Retention does not delete records, it deletes segments, and only after they are closed. An active segment keeps growing until it reaches segment.bytes or segment.ms, so each partition carries up to one extra segment beyond what retention permits, on each replica. Lowering segment.bytes reduces the slack and increases the file count; the report gives both so the trade is visible.
Size for the peak, because retention holds it
Retention keeps the busiest hour for the whole retention window, so an average-based estimate is wrong for as long as the window lasts. If traffic doubles for an hour a day and retention is a week, that hour is on disk seven times over.
What this cannot see
It does not know your topic count, your actual compression, whether compaction is enabled, or how much of your disk the operating system and the page cache want. A compacted topic behaves differently: its size depends on the number of distinct keys rather than on retention, so these figures are for a delete-policy topic. For the cluster-wide question of how many brokers, and for the replication traffic that comes with the replication factor, the cluster sizing calculator answers the other half.