Best tools to reassign Kafka partitions
ComparisonsThe 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.
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.
At a glance
Seven options are scored here on this page's six weighted criteria, 120 points in all. The rubric is weighted: Progress and cancellation counts twice, Access control and audit counts five times, Fit and running cost counts twice, and Plan generation, Throttling and Batching and blast radius count once. The five listed first, of seven, each out of 120: Kpow 84, which takes its best score on Progress and cancellation (9 out of 10) and its lowest on Throttling (0 out of 10); Cruise Control 79; Strimzi KafkaRebalance 78; topicctl 76; kafka-reassign-partitions.sh 56.
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, the 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.
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.
| Rank | Tool | Plan generation | Throttling | Batching | Progress and cancel | Access control and audit | Fit and running cost | Source |
|---|---|---|---|---|---|---|---|---|
| 1 | 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 |
| 2 | 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 |
| 3 | 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 |
| 4 | 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 |
| 5 | 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 |
| 6 | 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” |
| 7 | 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 |
| 8 | 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 |
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
84 out of 120 Total
Try Kpow in the live demo No signup needed.
- 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 ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 9 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
Why these scores for Kpow
- Plan generation 2 out of 10
- You choose target replicas one partition at a time and Kpow proposes no plan, which this page’s table rates “Manual”. Cruise Control beats it outright, per the page.
- Throttling 0 out of 10
- Throttling is “None in the UI”, so you throttle a large move with the CLI or Cruise Control.
- Batching and blast radius 3 out of 10
- Batching is “Manual, one partition per action”. Cruise Control beats it outright, per the page.
- Progress and cancellation 9 out of 10
- A Reassignment view lists every in-progress move with its latest status and cancels any of them, which this page’s table rates “Strong”, and the page’s summary names per-partition control from a UI as a Kpow strength.
- Access control and audit 9 out of 10
- It has the only “Strong” in the access column, for RBAC with allow, deny or stage effects and an audit log with webhook, and the page’s summary names it as a Kpow strength. RBAC and audit need Enterprise.
- Fit and running cost 8 out of 10
- One container also covers the rest of Kafka operations, a “Light” on this page’s table, licensed per cluster with a free Community Edition up to three clusters.
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 the comparison of broker health monitoring tools covers the options for that.
Staying patched. Kpow’s release notes name the CVEs each release remediates, and the 96.4 image built on 5 August 2026 bundles 311 dependencies of which one carries a high or critical advisory, none of them published before that release. That is not a claim to patch faster than a community project: Kpow’s own dependency remediation has run from 14 to 128 days, and the current image still ships CVE-2026-75595 in netty, a 9.1 critical public since 19 August 2026, unpatched. What a licence buys here is not a different deployment model, because Kpow is self-hosted too. It is a company contracted to ship the fix. Every dependency figure on this page was read on 24 September 2026 from the published artefacts and from nvd.nist.gov.
Cruise Control
79 out of 120 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 ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 6 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
Why these scores for Cruise Control
- Plan generation 10 out of 10
- The page’s own prose calls it “The only open-source option here that treats the plan as an optimization problem” across disk, CPU, network, rack and leadership, and the page’s summary has it beating Kpow outright on plan generation.
- Throttling 8 out of 10
- It takes replication_throttle per request or default.replication.throttle, a “Strong” on this page’s table, and the page’s summary has it beating Kpow outright on throttling.
- Batching and blast radius 9 out of 10
- Batches are capped per broker (num.concurrent.partition.movements.per.broker, default 5), which this page’s table rates “Strong”, and the page’s summary has it beating Kpow outright on batching.
- Progress and cancellation 8 out of 10
- It exposes REST API execution state and stop_proposal_execution, with dry runs by default, which this page’s table rates “Strong”.
- Access control and audit 6 out of 10
- Access is “Partial”, with pluggable authentication, VIEWER/USER/ADMIN roles and optional two-step verification, and audit only from logs and user task history.
- Fit and running cost 3 out of 10
- A separate stateful service, a metrics reporter JAR on every broker and a capacity file to maintain make it “Heavy”.
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.
Staying patched. Cruise Control is Apache-2.0 and actively maintained: twelve releases in two years, a published security policy, and no CVE filed against its own code. The gap to plan for is cadence rather than disclosure. It went 209 days between November 2025 and May 2026, and a fix to a bundled library reaches you only when the next release carries it, because nobody is contracted to cut one for you.
Rank 3 Strimzi KafkaRebalance
78 out of 120 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 ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 6 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
Why these scores for Strimzi KafkaRebalance
- Plan generation 9 out of 10
- It runs Cruise Control goals underneath, plus add/remove-broker modes and auto-rebalance on node pool changes, which this page’s table rates “Strong”.
- Throttling 8 out of 10
- A replicationThrottle sits on the resource, which this page’s table rates “Strong”.
- Batching and blast radius 9 out of 10
- Cruise Control batching applies, plus replica movement strategies such as small partitions first, another “Strong” on this page’s table.
- Progress and cancellation 7 out of 10
- Status sits on the resource and a stop annotation halts it, but stopping finishes the current batch first and the docs warn the intermediate state can perform worse.
- Access control and audit 6 out of 10
- Kubernetes RBAC covers who creates the resource and GitOps history is the audit trail, a “Partial” on this page’s table.
- Fit and running cost 4 out of 10
- It works only for Kafka run by the Strimzi operator on Kubernetes.
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.
Staying patched. Strimzi is community-maintained under the CNCF and it answers the patching question better than most vendors do. Thirty-eight releases in two years, six published CVEs, each with a coordinated-disclosure advisory, and on the last three batches the fixed release shipped the same day the advisory was published: 0.49.1 in December 2025, 0.50.1 in February 2026 and 1.0.1 in June 2026. Open source is not the risk here. The absence of a contract is, and Strimzi shows how little that has cost so far.
topicctl
76 out of 120 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 ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 6 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
Why these scores for topicctl
- Plan generation 5 out of 10
- It balances brokers per replica position within each topic and is not cluster-load aware, a “Partial” on this page’s table.
- Throttling 7 out of 10
- Replica migrations run under Kafka throttles by default, which this page’s table rates “Strong”, though the page does not say you can change the throttle mid-move.
- Batching and blast radius 6 out of 10
- Work happens topic by topic, interruptible and idempotent, which this page’s table rates “Partial”.
- Progress and cancellation 5 out of 10
- Runs are interruptible and can be re-run, with no separate tracking view, another “Partial”.
- Access control and audit 6 out of 10
- Changes go through YAML in Git with a confirmation per mutation, so review happens in the pull request, which this page’s table rates “Partial”.
- Fit and running cost 9 out of 10
- It is “Light”, a single Go binary with no ZooKeeper needed in v1.
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.
Staying patched. topicctl is MIT and actively released, twelve releases in two years and v2.0.2 in March 2026, with no CVE filed against its own code. Nobody is contracted to ship a patch for it, so the currency of what it bundles is yours to check.
Rank 5 kafka-reassign-partitions.sh
56 out of 120 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 ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 1 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 10 out of 10
Why these scores for kafka-reassign-partitions.sh
- Plan generation 3 out of 10
- Plan generation is “Weak”, because --generate spreads named topics over listed brokers with no view of load or disk, and makes no decommission plans.
- Throttling 8 out of 10
- It takes --throttle on execute, --additional changes it mid-move and --verify clears it, all three things criterion 2 asks for, and this page’s table rates it “Strong”.
- Batching and blast radius 4 out of 10
- You split the plan into batches yourself, which the comparison table on this page calls “Manual”.
- Progress and cancellation 8 out of 10
- A --verify run reports per-partition status, --list shows active moves and --cancel stops one, which this page’s table rates “Strong”.
- Access control and audit 1 out of 10
- Anyone with broker access can run it and the only record is shell history or a CI log, which this page’s table rates “None”.
- Fit and running cost 10 out of 10
- It ships with Kafka and there is nothing to run, the only option with no extra service, binary or platform.
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
53 out of 120 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 ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 3 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
Why these scores for Confluent Self-Balancing Clusters and Amazon MSK intelligent rebalancing
- Plan generation 8 out of 10
- Both are “Strong”, automatic on broker add and remove or uneven load (Confluent) and on scale up or down (MSK).
- Throttling 6 out of 10
- Throttling is “Handled by the feature” (Confluent) or “by the service” (MSK), and the page describes no throttle you control.
- Batching and blast radius 6 out of 10
- Batching is handled by the feature or service, with no batch control described.
- Progress and cancellation 5 out of 10
- Confluent progress through its metrics and Control Center, MSK through rebalancing metrics; the page describes no cancel for either.
- Access control and audit 3 out of 10
- Confluent is configured in Control Center or broker properties, MSK is turned on or paused through console, CLI or SDK; no roles, approval or audit described.
- Fit and running cost 4 out of 10
- Confluent Platform only, and MSK Express brokers only; Standard brokers and Apache Kafka still need another tool.
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)
23 out of 120 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 ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- Access control and audit ×5 weight, this criterion counts 5 times toward the total
- 0 out of 10
- Fit and running cost ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
Why these scores for topicmappr (kafka-kit)
- Plan generation 7 out of 10
- This page’s table rates it “Strong for storage” for minimal-movement broker replacement and bin-packing by size and capacity, with rack awareness, but not leadership or traffic.
- Throttling 5 out of 10
- It throttles only through the autothrottle companion service, which depends on Datadog API metrics.
- Batching and blast radius 5 out of 10
- Batching is “Partial” because you control the scope of each map.
- Progress and cancellation 1 out of 10
- Progress is “Not built in” because it writes a plan for the Kafka CLI to execute.
- Access control and audit 0 out of 10
- Access control and audit are “None built in”.
- Fit and running cost 2 out of 10
- It is tested against Kafka 0.10 and 2.2 to 2.7 with ZooKeeper, and topic discovery reads ZooKeeper, so on KRaft you feed it a JSON map.
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.
Staying patched. topicmappr ships inside Datadog’s kafka-kit, Apache-2.0, actively pushed across thirty releases, with no CVE filed against its own code. It is a planning binary you run and discard rather than a service you leave listening, which is the smaller of the two exposures.
How Factor House approaches reassignment
Factor House 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.
Factor House has not built a goal-based planner or a throttle into the product. For a cluster-wide rebalance, its 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 the 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 the 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.
How these tools were scored
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, Factor House’s co-founder and CEO, made the point while Factor House was 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. Chad Harris’s own rule, from the Kafka 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. The comparison of Kafka audit logging tools covers the record part in depth. Tom Crowley, Factor House’s 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
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Plan generation counts once, Throttling counts once, Batching and blast radius counts once, Progress and cancellation counts twice, Access control and audit counts five times and Fit and running cost counts twice, for a total out of 120. Access control and audit counts five times here, and progress and cancellation and fit and running cost twice each, because a reassignment moves production data between brokers and this page is written around whether that move can be attributed, watched and stopped. Plan generation, throttling and batching and blast radius count once, and those three are the criteria the dedicated rebalancers on this page win outright. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 84 out of 120. The other options follow by total.