Kafka Partition Calculator
Calculate the partition count a topic needs from producer and consumer throughput, check it against broker limits, and size the disk that retention actually requires.
Last reviewed by the Radiatus Cloud team
Want this automated for your stack?
We build CI/CD, Kubernetes & IaC pipelines that scale.
Partitions are the unit of parallelism
A Kafka partition is consumed by exactly one consumer within a group, so the partition count sets the maximum useful parallelism. Twelve consumers on a six partition topic means six of them sit idle. That single constraint is the main input to the decision, and it is why partition counts are usually chosen from the consumer side rather than the producer side. The standard formula takes the target throughput and divides by the lower of what a single producer or a single consumer can sustain.
Increasing partitions is easy, decreasing is not
Partitions can be added to a topic at any time, and they cannot be removed. Adding them also breaks key ordering, because the default partitioner hashes the key modulo the partition count, so an existing key can move to a different partition and its messages can be consumed out of order relative to its history. For a topic where ordering per key matters, the partition count is effectively permanent, which argues for a modest amount of headroom at creation.
Every partition costs on the broker
Each partition replica is a set of open file handles, a memory buffer and an entry in the controller's metadata. Historically a cluster was limited to a few thousand partitions per broker; KRaft mode raised this substantially, but the per partition cost remains real and recovery time after a broker restart scales with it. Tens of thousands of partitions across a cluster is normal, hundreds of thousands is a design problem.
Related tools
- CI/CD Security Gap Analyzer — Checklist based analyzer for CI/CD pipeline security gaps.
- Docker Security Scanner — A new tool extracted from the codebase.
- Terraform Scanner — A new tool extracted from the codebase.
- SQL Formatter — Format and indent SQL queries for readability. Handles joins, subqueries and CTEs, supports common dialects, and runs entirely in your browser.
Frequently Asked Questions
How do I choose a partition count?
Take your target throughput and divide by the lower of single partition producer throughput and single consumer throughput, then add headroom. The consumer side usually binds, because consumers do real work per message while producers mostly write.
Can I reduce the partition count later?
No. Partitions can only be added. Reducing means creating a new topic and migrating, so it is worth a modest amount of headroom at creation rather than sizing exactly to today.
What breaks when I add partitions?
Key based ordering. The default partitioner hashes the key modulo the partition count, so adding partitions moves existing keys to different partitions and their messages can then be consumed out of order relative to their history. For ordered topics, treat the count as fixed.
How many consumers can I run?
At most one per partition within a consumer group. Extra consumers idle. Multiple independent groups each get the full stream, so the limit applies per group rather than across the cluster.
What replication factor should I use?
Three for anything that matters, with min.insync.replicas of two and acks=all on the producer. That tolerates one broker loss without data loss and without blocking writes. A replication factor of two with min.insync.replicas of two blocks all writes when any broker goes down.
Privacy & Security
Everything runs in your browser; nothing is uploaded.
How to Use
Enter your throughput targets and consumer capacity to get a partition count and retention sizing.
Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.