The best tool to reassign Kafka partitions depends on who decides the target layout. kafka-reassign-partitions.sh ships with Kafka and moves whatever plan you give it. Cruise Control, and Strimzi on Kubernetes, compute a balanced plan against goals and execute it in throttled batches. topicctl and topicmappr sit between the two, and Kpow gives you a UI to reassign individual partitions, watch progress and cancel moves. Confluent Platform and Amazon MSK Express brokers have their own built-in rebalancers. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option.
Reassignment moves partition replicas from one set of brokers to another, usually after adding brokers, before removing one, or to relieve a hot broker. Kafka does not do it on its own: new brokers get no existing partitions until something moves them. For the wider operating picture, start with the complete Kafka guide.
When you need a reassignment tool
Three situations send people looking for a better tool than the one Kafka ships.
Cluster expansion. You added brokers and they sit idle. The Apache operations guide says new servers “will not automatically be assigned any data partitions, so unless partitions are moved to them they won’t be doing any work until new topics are created.”
Broker decommissioning. A broker is failing or being retired, and every replica on it has to move first. Apache notes the CLI “does not have the ability to automatically generate a reassignment plan for decommissioning brokers yet”, so without another tool that plan is written by hand.
Hot spots. One broker is running out of disk or carrying too much leadership. If you have not yet worked out which kind of imbalance you have, our guide to diagnosing an unbalanced Kafka cluster walks through the metrics that separate leader imbalance, data imbalance and key skew. Key skew is not fixed by any tool on this page.
How we score reassignment tools
Every tool here ends up calling the same Kafka primitive, the partition reassignment Admin API added in KIP-455. What separates them is how much of the surrounding work they do for you, and how safe they make it. These are the six criteria, and why each one matters in production.
1. Plan generation. Something has to decide which broker holds which replica, partition by partition, and in which order, because the first replica becomes the preferred leader. The Kafka CLI does the first part naively and the second part not at all. Derek Troy-West, our co-founder and CEO, made the point while we were building reassignment into Kpow: a plan that sets every partition to the same replica list gives one broker leadership of the whole topic. A good tool proposes a plan that balances disk, traffic and leadership together, and shows it to you before any data moves.
2. Throttling. A reassignment copies replica data over the same network that serves producers and consumers. Kafka supports a replication throttle, and Apache is explicit about two failure modes: a throttle left in place after the move keeps capping normal replication, and a throttle set below the incoming write rate means replication never catches up. A good tool sets the throttle, lets you change it mid-move, and removes it when the move completes.
3. Batching and blast radius. Moving thousands of partitions in one plan saturates the cluster and makes it impossible to tell which move caused which symptom. My own rule, from our operational issues talk, is “one change at a time, monitored before the next”. For reassignment that means small batches with a check between them.
4. Progress and cancellation. A large move runs for hours. Derek noted in the same engineering discussion that the Admin API can “monitor ongoing reassignments cos they can take time”, and that throttling and progress monitoring were the harder part of the job. You need to see how far a move has got, and be able to stop it when something else breaks mid-move, which happens often enough to plan for.
5. Access control and audit. Reassignment moves production data. Who is allowed to start one, whether someone else approves it, and whether there is a record of who did it matter as much for this operation as for deleting a topic. Our comparison of Kafka audit logging tools covers the record part in depth. Tom Crowley, our founding engineer, describes Kpow’s answer to the approval part simply: “We have optional approval via staged mutations”.
6. Fit and running cost. Kafka 4.0 removed ZooKeeper, so a tool that reads cluster state from ZooKeeper cannot see a current cluster. A tool that needs its own service, a metrics reporter on every broker, or Kubernetes is only cheap if you already run those things.
You need to be able to set the partition reassignments individually for each partition in a topic. If you set them all to the same thing (e.g. 1,2,3) then leadership would be the same for every partition in a topic, e.g. every partition in that topic would have broker leader 1
Derek Troy-West, Co-founder and CEO of Factor House
The tools compared
Every row uses the same fields in the same order. Where a tool is strong on a criterion the cell says why, and where it is weak it says what you would do instead.
| Tool | Plan generation | Throttling | Batching | Progress and cancel | Access control and audit | Fit and running cost | Source |
|---|---|---|---|---|---|---|---|
| kafka-reassign-partitions.sh | Weak. --generate spreads the topics you name across the brokers you list, with no view of load or disk (it is rack-aware unless you pass --disable-rack-aware), and does not generate decommission plans. |
Strong. --throttle on execute, --additional to change it mid-move, and --verify clears it. |
Manual. You split the plan into batches yourself. | Strong. --verify reports per-partition status, --list shows active reassignments and --cancel stops an active one. |
None. Anyone with broker access and the script can run it, and the only record is your shell history or CI log. | Ships with Kafka, nothing to run. | Apache Kafka operations |
| Cruise Control | Strong. Multi-goal proposals covering rack awareness, disk, CPU, network, replica and leader distribution, plus custom goals. Handles add, remove and demote broker. | Strong. replication_throttle per request or default.replication.throttle as a default. |
Strong. Executes in batches capped per broker (num.concurrent.partition.movements.per.broker, default 5). |
Strong. REST API reports execution state and stop_proposal_execution stops a run. Requests are dry runs unless you set dryrun=false. |
Partial. Pluggable authentication, three built-in roles (VIEWER, USER, ADMIN) and optional two-step verification that holds POST requests for review. Audit comes from its logs and user task history. | Heavy. A separate service, a metrics reporter JAR on every broker, and a broker capacity file to maintain. | Cruise Control |
| Strimzi KafkaRebalance | Strong. Cruise Control underneath, with goals set in the Kafka and KafkaRebalance resources, and auto-rebalance when a node pool’s broker count changes. |
Strong. replicationThrottle on the resource. |
Strong. Same batching as Cruise Control, plus replica movement strategies such as moving small partitions first. | Strong. Status on the resource, and a stop annotation finishes the current batch then stops. |
Partial. Kubernetes RBAC controls who can create the resource, and your GitOps history is the audit trail. Cruise Control self-healing is not supported in Strimzi. | Only for Kafka run by the Strimzi operator on Kubernetes. | Strimzi documentation |
| topicctl | Partial. apply --rebalance rebalances brokers per replica position within each topic, and a placement strategy (such as cross-rack or in-zone) is declared per topic in YAML. Not cluster-load aware. |
Strong. Replica migrations run under Kafka throttles by default. | Partial. Topic by topic, interruptible and idempotent. | Partial. Runs are interruptible and can be re-run. There is no separate tracking view. | Partial. Changes go through YAML in Git and each mutation needs a confirmation, so review happens in the pull request. | Light. A single Go binary, no ZooKeeper needed in v1. | topicctl |
| topicmappr (kafka-kit) | Strong for storage. Minimal-movement broker replacement and storage bin-packing by partition size and broker capacity, with rack awareness. | Via a companion service, autothrottle, which paces throttles from Datadog API metrics. | Partial. You control the scope of each map. | Not built in. It writes a plan for the Kafka CLI to execute. | None built in. | Its README lists testing against Kafka 0.10 and 2.2 to 2.7 with ZooKeeper, and topic discovery reads ZooKeeper, so on a KRaft cluster you would feed it a JSON map. | kafka-kit |
| Kpow | Manual. You choose the target replicas for one partition at a time. Kpow does not propose a balanced plan, and full topic and cluster reassignment is not in the current release. | None in the UI. Throttle a large move with the CLI or Cruise Control. | Manual, one partition per action. | Strong. A Reassignment view lists every in-progress move with its latest status and cancels any of them. | Strong. RBAC per role and resource with allow, deny or stage effects, and every mutation is written to an audit log that can also go to a webhook. | Light. One container that also covers the rest of Kafka operations. Licensed per cluster, with a free Community Edition for up to three clusters. | Kpow topic management docs |
| Confluent Self-Balancing Clusters | Strong. Automatic rebalancing on broker add and remove, or on any uneven load, with plans generated from aggregated metrics. | Handled by the feature. | Handled by the feature. | Progress visible through its metrics and in Control Center. | Configured in Control Center or in broker properties. | Confluent Platform only, not Apache Kafka. | Confluent’s documentation, “Manage Self-Balancing Kafka Clusters in Confluent Platform” |
| Amazon MSK intelligent rebalancing | Strong. Automatic on scale up or down, plus continuous monitoring for imbalance. | Handled by the service. | Handled by the service. | Exposed through MSK rebalancing metrics. | Turned on or paused through the MSK console, CLI or SDK. | Express brokers only, on by default for new Express clusters. Standard brokers still need one of the tools above. | Amazon MSK documentation |
Two scoring notes. Cruise Control beats Kpow outright on plan generation, throttling and batching, and those are the criteria that decide a cluster-wide rebalance. Kpow’s strengths here are per-partition control from a UI, access control with staged approval, and an audit log shared with every other Kafka operation, which matter most when the people running reassignments are not all Kafka specialists.
Kpow live demo
Test reassignment in a Kafka UI
Explore partition replica lists, preferred leaders and the reassignment view in the Kpow demo, then compare it with the CLI and Cruise Control on this page.
For teams where more than Kafka specialists move partitions.
Try the Kpow demoEach option in detail
Legacy tools that still show up in search
CMAK, formerly Kafka Manager, can generate assignments, run reassignments and trigger preferred replica elections, but it keeps its state in ZooKeeper and was last updated in 2023. kafkabalancer computes one minimal rebalancing step at a time for use in an automation loop, and kafka-reassign-tool generates minimal-change plans for replication factor changes, decommissioning and leader balance. Both read cluster state from ZooKeeper, so none of the three can see a cluster running Kafka 4.x. General Kafka UIs are not a substitute either: neither AKHQ’s nor Kafbat UI’s permission model includes a partition reassignment action.
Rank 1 Kpow
31 out of 60 Total
Listed first because it is our product. Scores are unadjusted.
- Type
- Kafka management UI
- Scope
- One partition per action
- RBAC, staging, audit log
- Enterprise
- Plan generation
- 2 out of 10
- Throttling
- 0 out of 10
- Batching and blast radius
- 3 out of 10
- Progress and cancellation
- 9 out of 10
- Access control and audit
- 9 out of 10
- Fit and running cost
- 8 out of 10
What it is. Factor House’s Kafka management and monitoring product.
Where it wins. Visibility and control during the move. From a topic’s details page you reassign a partition to the replicas you choose, then the Reassignment view shows the latest status of every in-progress reassignment and cancels any of them, a capability added in release 92.3. Access is controlled per role and resource, staged mutations add an approval step, and every mutation is recorded in the audit log. The same console shows under-replicated partitions and preferred-leader percentages, so you can watch the cluster recover while the move runs.
Where it falls short. It reassigns one partition at a time, it does not generate a balanced plan, and it has no throttle control. For a cluster-wide rebalance, Cruise Control or the CLI does the moving.
Run it safely. Throttle large moves at the Kafka level first, then use Kpow to track the move and cancel it if under-replicated partitions climb on unrelated topics. Whatever tool does the moving, watch replication health throughout, and our comparison of broker health monitoring tools covers the options for that.
Cruise Control
44 out of 60 Total
- Type
- Goal-based rebalancing service
- Origin
- Built at LinkedIn
- Default batch
- 5 partition moves per broker
- Plan generation
- 10 out of 10
- Throttling
- 8 out of 10
- Batching and blast radius
- 9 out of 10
- Progress and cancellation
- 8 out of 10
- Access control and audit
- 6 out of 10
- Fit and running cost
- 3 out of 10
What it is. An open-source rebalancer originally built at LinkedIn, whose README describes clusters of “10K+ Kafka brokers” as the reason it exists. It monitors broker, topic and partition resource use, generates proposals against goals, and executes them.
Where it wins. It is the only open-source option here that treats the plan as an optimization problem across disk, CPU, network, rack and leadership at once. Its executor moves partitions in capped batches with a replication throttle, and every POST action defaults to a dry run, so data only moves when you ask for it. It also detects broker and disk failures, goal violations and slow brokers, with self-healing off by default.
Where it falls short. It is another stateful service to run and patch, it needs CruiseControlMetricsReporter loaded into every broker, and its proposals are only as good as the broker capacity file you give it. There is a separate Cruise Control UI project, and its security documentation covers authentication and the three built-in roles.
Run it safely. Start with dry runs, set default.replication.throttle, and keep the per-broker concurrency low until you have watched a few executions. The REST API reference documents every endpoint and parameter.
Rank 3 Strimzi KafkaRebalance
43 out of 60 Total
- Type
- Kubernetes custom resource
- Engine
- Cruise Control
- Runs on
- Strimzi-managed Kafka
- Plan generation
- 9 out of 10
- Throttling
- 8 out of 10
- Batching and blast radius
- 9 out of 10
- Progress and cancellation
- 7 out of 10
- Access control and audit
- 6 out of 10
- Fit and running cost
- 4 out of 10
What it is. Strimzi’s operator deploys Cruise Control alongside a Kafka cluster on Kubernetes and exposes rebalances as a KafkaRebalance custom resource.
Where it wins. Rebalancing becomes a declarative resource with a status, which fits a GitOps workflow. It supports add-brokers and remove-brokers modes, intra-broker disk balancing on JBOD, and auto-rebalancing when you change a node pool’s replica count. On Kafka 4.3 and later, brokers scheduled for removal are cordoned automatically during scale-down.
Where it falls short. It only applies to Strimzi-managed clusters, and the Strimzi docs note that Cruise Control self-healing is not supported. Stopping a rebalance finishes the current batch first, and the docs warn the cluster can perform worse in that intermediate state than before the rebalance started.
Run it safely. Review the optimization proposal in the resource status before approving it, and set replicationThrottle and a replica movement strategy on the resource.
topicctl
38 out of 60 Total
- Type
- Declarative topic tool (YAML)
- From
- Segment
- Runs as
- A single Go binary
- Plan generation
- 5 out of 10
- Throttling
- 7 out of 10
- Batching and blast radius
- 6 out of 10
- Progress and cancellation
- 5 out of 10
- Access control and audit
- 6 out of 10
- Fit and running cost
- 9 out of 10
What it is. Segment’s open-source tool for declarative topic management in YAML, with a rebalance command.
Where it wins. Reassignment happens as part of the same Git-reviewed workflow that manages topic config. Its README lists the safety properties plainly: every mutation needs user confirmation, apply runs are interruptible and idempotent, partition changes are locked per cluster, and replica migrations run under throttles.
Where it falls short. Its rebalancing balances brokers within each topic by replica position, not whole-cluster disk or CPU load. It will also skip a topic whose partition count or retention in the cluster does not match its YAML.
Run it safely. Use apply --rebalance on a single topic first, then the rebalance subcommand for a prefix of topics.
Rank 5 kafka-reassign-partitions.sh
34 out of 60 Total
- Type
- Command-line tool
- Ships with
- Apache Kafka
- Modes
- --generate, --execute, --verify
- Plan generation
- 3 out of 10
- Throttling
- 8 out of 10
- Batching and blast radius
- 4 out of 10
- Progress and cancellation
- 8 out of 10
- Access control and audit
- 1 out of 10
- Fit and running cost
- 10 out of 10
What it is. The reassignment tool in every Apache Kafka distribution, with three modes: --generate, --execute and --verify.
Where it wins. It is always there, it supports throttling properly, and it is the thing every other tool’s documentation assumes you understand. For a one-off move of a few topics onto new brokers it is enough.
Where it falls short. Apache states that it “does not have the capability to automatically study the data distribution in a Kafka cluster and move partitions around to attain an even load distribution”. You decide the target, you write the decommission plan by hand, and you batch the work yourself. It also has no concept of who is running it. It does have --list and --cancel options for active reassignments, documented in the command’s option definitions.
Run it safely. Execute with --throttle, watch follower lag fall, and run --verify at the end to clear the throttle. The Apache throttling section has the full procedure.
Confluent Self-Balancing Clusters and Amazon MSK intelligent rebalancing
32 out of 60 Total
- Covers
- Confluent Platform, MSK Express brokers
- Type
- Built-in rebalancers
- Plan generation
- 8 out of 10
- Throttling
- 6 out of 10
- Batching and blast radius
- 6 out of 10
- Progress and cancellation
- 5 out of 10
- Access control and audit
- 3 out of 10
- Fit and running cost
- 4 out of 10
What they are. Built-in rebalancers from two managed or commercial distributions. Confluent’s documentation describes Self-Balancing Clusters as automatically rebalancing partitions when brokers are added or removed, or whenever load is uneven, and as the preferred alternative to its older Auto Data Balancer. The Amazon MSK documentation describes intelligent rebalancing as automatic on scale up and down for Express brokers.
Where they win. If you run one of these platforms, they remove the planning and execution work entirely.
Where they fall short. Each works only on its own platform. MSK Standard brokers, Apache Kafka and every other distribution still need one of the tools above.
topicmappr (kafka-kit)
20 out of 60 Total
- Type
- Plan generator
- Focus
- Broker replacement, storage placement
- Executes with
- The Kafka CLI
- Plan generation
- 7 out of 10
- Throttling
- 5 out of 10
- Batching and blast radius
- 5 out of 10
- Progress and cancellation
- 1 out of 10
- Access control and audit
- 0 out of 10
- Fit and running cost
- 2 out of 10
What it is. A tool in Datadog’s open-source kafka-kit that replaces and extends the Kafka reassignment tool, focused on minimal-movement broker replacement and storage-based placement.
Where it wins. Replacing a failed broker with the smallest possible data movement, and bin-packing partitions by size onto brokers by capacity, which the Kafka CLI cannot do.
Where it falls short. It is documented against ZooKeeper-era Kafka versions, and its autothrottle companion depends on the Datadog API for metrics.
Run it safely. Treat its output as a plan to review, then execute and throttle it with the Kafka CLI.
How Factor House approaches reassignment
We built reassignment into Kpow for the part of the job the CLI leaves to whoever holds a terminal on the cluster: letting a wider team see what is moving, stop it, and know who started it. You set a partition’s target replicas from its details page, the Reassignment view tracks and cancels in-progress moves, and the same screen that ran the move shows under-replicated partitions calculated per topic partition, so the count stays correct even when a broker is offline and missing from the AdminClient’s view.
We have not built a goal-based planner or a throttle into the product. For a cluster-wide rebalance, our advice is the same as for any team: plan and throttle it with Cruise Control or the CLI, and use Kpow to watch it. Signals, an opt-in Alpha feature for Kpow Enterprise added in 96.3, flags brokers holding a disproportionate share of partition leadership or replica data, which is often how people discover they need a reassignment in the first place. It is off by default and may add overhead on large clusters. The Kpow topic management documentation covers the reassignment and leader election workflow step by step. If you want to judge the UI side for yourself before deciding, the Kpow demo lets you open a topic’s partitions, see replica lists and preferred leaders, and find the Reassign Partition and Elect Leader actions and the Reassignment tab on a live cluster.
How to choose
One-off moves after adding brokers. The CLI with a throttle is enough, and Kpow makes the per-partition fixes and the monitoring easier if you already run it.
Frequent or cluster-wide rebalancing. Cruise Control, or Strimzi’s integration if you run Kafka on Kubernetes. This is the case goal-based planning exists for.
Topic config already managed in Git. topicctl keeps reassignment inside the same reviewed workflow, and our comparison of Kafka topic management tools covers the rest of that workflow.
Confluent Platform or MSK Express. Use the built-in rebalancer first and keep one of the open-source tools for the cases it does not cover.
Several teams share the cluster. Put access control, approval and audit in front of whatever does the moving. Kafka cluster management covers the wider operating model, and our broader Kafka management tools comparison looks at the consoles beyond this one job.
FAQ
What is the best tool for Kafka partition reassignment?
For a cluster-wide rebalance, Cruise Control, because it computes a balanced plan against goals and executes it in throttled batches. For occasional moves, kafka-reassign-partitions.sh with --throttle is enough. If you want a UI with cancellation, access control and an audit trail, Kpow covers per-partition reassignment, though it does not generate plans.
Does Kafka rebalance partitions automatically?
Apache Kafka restores preferred leaders automatically but does not move replica data. New brokers receive no existing partitions until you reassign them. Confluent Self-Balancing Clusters and Amazon MSK Express brokers add automatic rebalancing on their own platforms.
Can I cancel a Kafka partition reassignment?
Yes. kafka-reassign-partitions.sh --cancel stops an active reassignment. Cruise Control exposes cancellation through stop_proposal_execution, Strimzi through a stop annotation on the KafkaRebalance resource, and Kpow through the cancel action in its Reassignment view. Moves that already completed stay completed.
Is partition reassignment the same as a consumer group rebalance?
No. Partition reassignment moves replicas between brokers. A consumer group rebalance redistributes partitions among a group’s consumers when membership changes, covered in what is Kafka rebalancing.