# Will Your Cassandra Database Project Succeed?: The New Stack

[Blog](/blog/)&gt;[Technology](/blog/category/technical/)&gt;Automated horizontal scaling for Apache Kafka® on NetApp Instaclustr 

Automated horizontal scaling for Apache Kafka® on NetApp Instaclustr
====================================================================

November 10, 2026 | By [ Varun Ghai](https://www.instaclustr.com/blog/author/varun-ghai/)

 

 

 

 



   [ ](https://x.com/intent/tweet?text=Automated%20horizontal%20scaling%20for%20Apache%20Kafka%C2%AE%20on%20NetApp%20Instaclustr&url=https://www.instaclustr.com/blog/automated-horizontal-scaling-apache-kafka-netapp-instaclustr/) [ ](https://www.linkedin.com/shareArticle?mini=true&url=https://www.instaclustr.com/blog/automated-horizontal-scaling-apache-kafka-netapp-instaclustr/&title=&summary=Automated%20horizontal%20scaling%20for%20Apache%20Kafka%C2%AE%20on%20NetApp%20Instaclustr&source=) 

NetApp is introducing customer-initiated automated horizontal scaling for Instaclustr for Apache Kafka. Customers can now add or remove broker nodes through the NetApp Instaclustr Console, application programming interface (API) or Terraform provider, while the platform coordinates the operational work needed to help complete the change safely.

The new workflow brings health checks, broker provisioning or removal, partition reassignment, and progress tracking into a single managed operation. Customers can respond to changing capacity requirements without first opening a support ticket and waiting for the operation to be started manually.

Scaling should not create another operational bottleneck
--------------------------------------------------------

Kafka workloads change. New applications, seasonal traffic, retention changes, and shifts in producer or consumer behavior can all alter the capacity a cluster needs. Adding brokers can provide more compute, storage, and network capacity. Removing brokers can reduce excess capacity when requirements fall.

The broker count is only part of the change. Kafka must remain healthy, partition replicas must be placed correctly, and the remaining brokers must have enough capacity to carry the resulting load. A scaling request that changes infrastructure without coordinating these steps can leave Operations teams with more work and more risk.

Automated horizontal scaling treats the complete change as one managed workflow. Horizontal scaling changes the number of brokers in a data center. Instaclustr also supports [vertical scaling](https://www.instaclustr.com/support/documentation/kafka/kafka-cluster-operations/scaling-your-cluster-vertically/) which changes the size of the broker nodes.

One scaling experience, in either direction
-------------------------------------------

Customers start an eligible operation from the cluster’s **Scaling** page in the NetApp Instaclustr Console, select horizontal scaling, and choose the target broker count. The same capability is also available through the API and Terraform for teams that manage infrastructure programmatically.

The platform then coordinates the operation and reports progress through the stages that matter, including pre-scale checks, node provisioning or selection, partition reassignment, drain verification, and completion. If a specified failure requires intervention, the NetApp Instaclustr Support team is notified.

This is designed to give Operations and platform engineering teams:

- **Fewer handoffs.** Start eligible scaling operations directly instead of using a support ticket as the trigger.
- **Built-in operational safeguards.** Validate cluster health and capacity before making the change.
- **Automated partition movement.** Rebalance replicas as part of the scaling workflow instead of treating reassignment as a separate manual task.
- **Clear progress visibility.** Follow each stage from the Console while the operation runs.
- **More responsive capacity management.** Adjust broker count as workload requirements change.

Add brokers and rebalance automatically
---------------------------------------

When customers add brokers, NetApp Instaclustr checks that the cluster is healthy before provisioning the new nodes. After the brokers join the cluster, [the workflow reassigns](https://www.instaclustr.com/support/documentation/kafka/useful-concepts/partition-reassignment/) existing partition replicas so the new capacity can carry its share of the workload.

The Console shows progress through the health-check, provisioning, and reassignment stages. Customers do not need to coordinate node creation and partition movement as separate activities.

Remove brokers only when the cluster can support it
---------------------------------------------------

Scaling down requires a different set of safeguards. Before removing brokers, NetApp Instaclustr checks cluster and broker health, replication, available disk capacity, and projected resource utilization on the brokers that will remain. If the cluster does not have sufficient headroom, the operation does not proceed.

For an eligible request, the workflow selects the brokers to remove and moves their partition replicas to the remaining brokers. It verifies that the selected brokers are drained before deleting and unregistering them. This sequence helps prevent broker removal from getting ahead of Kafka’s data-placement requirements.

Customers can run sequential operations when they need to make a larger reduction, subject to the eligibility and capacity checks applied to each request.

Current eligibility and limits
------------------------------

The current release supports customer-initiated operations for data centers with no more than 30 Kafka brokers before scaling, with up to three brokers added or removed in one operation. Over the coming months, we will work to do away with these restrictions. Remove-node operations are not currently available for data centers using Amazon Web Services (AWS) PrivateLink, Azure Private Link, or Google Cloud Private Service Connect.[\[1\]](https://www.instaclustr.com/support/documentation/kafka/kafka-cluster-operations/horizontal-scaling-scaling-up/)

These limits define the customer-initiated workflow, not the full range of changes the NetApp Instaclustr Support team can perform. Customers with larger clusters, larger requested changes, or excluded network configurations should contact Support to plan the operation.

Get started
-----------

Open an eligible Kafka cluster in the NetApp Instaclustr Console, select **Scaling**, and choose **Horizontal Scaling**. Review the target broker count and operation summary before starting the workflow.

See the [Apache Kafka horizontal scaling documentation](https://www.instaclustr.com/support/documentation/kafka/kafka-cluster-operations/horizontal-scaling-scaling-up/) and [additional support page about removing nodes](https://www.instaclustr.com/support/documentation/kafka/kafka-cluster-operations/horizontal-scaling-scaling-down/) for preparation steps, current eligibility, limitations, API guidance, and detailed progress states. The [partition reassignment overview](https://www.instaclustr.com/support/documentation/kafka/useful-concepts/partition-reassignment/) explains how NetApp Instaclustr moves replicas while maintaining rack-aware placement.

 

### About the author

**[Varun Ghai](https://www.instaclustr.com/blog/author/varun-ghai/)** | Product Manager

With a keen focus on product management, Varun brings a wealth of experience and expertise to the team, driving innovation and excellence in the company's Apache Kafka offering.

 

 [ Add Instaclustr as a preferred source on Google ](https://google.com/preferences/source?q=instaclustr.com)



 

 ![mail icon]()#### Get the latest articles for open sourceIn your inbox

 <a class="btn btn-primary btn-popup text-dark" href="">Sign up now</a> 

 

 

 

  ### Related content

 [ Zero Downtime Migration to Instaclustr 

 

 Yes, we can migrate existing Cassandra clusters to Instaclustr without any downtime. Here's what to expect from the process... 

 

 

 

 

 

 

 ](https://www.instaclustr.com/blog/zero-downtime-migration-to-instaclustr/) 

 [ Workflow Comparison: Uber Cadence vs Netflix Conductor 

 

 When choosing what’s right for your company’s opensource workflow needs it is important to know the difference and similarities ... 

 

 

 

 

 

 

 ](https://www.instaclustr.com/blog/workflow-comparison-uber-cadence-vs-netflix-conductor/) 

 [ Will Your Cassandra Database Project Succeed?: The New Stack 

 

 Open source Apache Cassandra® continues to stand out as an enterprise-proven solution for organizations seeking high availability... 

 

 

 

 

 

 

 ](https://www.instaclustr.com/blog/will-your-cassandra-database-project-succeed-the-new-stack/) 

 

  <a class="close-modal" href="">×</a>Sign upto ourNewsletter
-----------------------
