Proven: Up to 73% Fewer Brokers With Confluent Private Cloud – and More

Every platform team that’s self-managing its Apache Kafka® deployment faces the same tension: The platform needs to grow, but the budget doesn’t. More teams want to stream data, and more applications need Kafka—but each new workload historically requires more clusters, more brokers, and more operational overhead. The result is cluster sprawl: dozens of underutilized Kafka clusters, each independently patched, monitored, and upgraded by a platform team that’s already stretched thin.

We’ve seen this play out across the entire spectrum of maturity. While a 10-cluster footprint is difficult, managing a 70-cluster estate is exponentially more complex. The math is unforgiving: Infrastructure costs compound linearly while the operational burden compounds super-linearly. Eventually, the platform team—instead of being the engine of innovation—becomes the bottleneck for every team that needs Kafka. 

At Current NOLA in 2025, we introduced Confluent Private Cloud (CPC) and promised an infrastructure cost reduction of up to 50%. Today, we’re proving that claim with hard benchmarking data. We’re giving you a sneak peek of our upcoming CPC release with broker-native multi-tenancy that eliminates cluster sprawl at the root. And we’re introducing CPC Centralized Policy Enforcement to enforce encryption, governance, and client behavior policies centrally at CPC Gateway, ensuring that only high-quality data flows through the system. 

Part 1: Benchmarking CPC Against Apache Kafka®

To prove our bold claims, we ran production-grade benchmarks comparing two primary Kafka distributions on identical infrastructure. For this benchmark, we standardized hardware, partition layouts, producer/consumer configurations, and KRaft controllers. Only the Kafka distribution and the broker count were adjusted to meet performance standards.

Our testing revealed four key findings that demonstrate how CPC fundamentally changes the economics of cloud-native data streaming for self-managed private cloud and on-premises environments.

Finding 1: Optimized for total cost of ownership – matching latency service level agreements (SLAs) with up to 73% fewer brokers

If you’re looking to eliminate cluster sprawl, the first step is to match your current performance on a much smaller hardware footprint. CPC with Intelligent Replication (IR) matches the p99 latency of Apache Kafka using a fraction of the brokers.  

At moderate throughput—where most enterprise production clusters operate—CPC with IR delivers up to 73% in broker savings. For example, if you’re currently running a 21-broker cluster on m5.4xlarge at 250 MB/s, CPC delivers the same latency with just 7 brokers. That’s 14 fewer servers to provision, monitor, patch, and pay for.

Finding 2: The no-cost performance unlock – up to 83% lower tail latency on same infrastructure 

If you keep your existing infrastructure unchanged and instead run on CPC with IR, the latency gains are dramatic, especially at higher loads. On an identical 21-broker footprint, CPC slashed tail latency by 83% even under heavy load. This allows you to support your most demanding applications on the hardware you already own—essentially providing a “free” hardware upgrade by making every existing broker significantly more efficient.

Finding 3: Eliminate the latency cliff – predictable performance even at peak saturation

In traditional Kafka architectures, there’s a “latency cliff”—a point where adding just a small amount of throughput causes response times to catastrophically spike. Our benchmarks indicate that while Apache Kafka exhibits a sharp latency cliff—a sudden, nonlinear p99 spike by more than 5x as throughput approaches saturation—CPC stays remarkably stable. CPC with IR eliminates this latency cliff entirely. 

Even as the system approaches saturation, CPC exhibits only a 16% increase in latency, giving you significantly more headroom before you need to scale out. This eliminates the need for massive, expensive over-provisioning. Traffic spikes that would normally cause Apache Kafka to breach SLAs are absorbed smoothly—no pages, no emergency scale-outs, no customer impact. By flattening the latency curve, CPC allows you to run your clusters at higher utilization with total peace of mind, knowing the system won’t choke when your business is at its busiest. 

Finding 4: Built for density – exponential savings for large-scale workloads

As clusters grow in complexity, the “management tax” on traditional brokers becomes a significant bottleneck—especially for workloads with tens of thousands of partitions. CPC was engineered to handle this density, and our testing indicates that the more complex your environment becomes, the more the architectural efficiency of IR pays off.

Even at a smaller scale of 4K partitions, CPC delivers a substantial 17%–50% reduction in broker requirements. But the true value is realized at higher density; for 14,000 partitions, those savings skyrocket to as much as 73%. When translated to a single cluster’s annual budget, the infrastructure savings are significant.

Part 2: Pre-Announcing Early Access – CPC Centralized Policy Enforcement

We’re excited to pre-announce the Early Access (EA) of CPC Centralized Policy Enforcement at Current London 2026, with General Availability (GA) planned for later in the year. Many customers’ Kafka environments often encounter the “wild west” client challenge, where hundreds of individual teams configure their own schemas and authentication practices, resulting in inconsistent encryption, governance gaps, and a massive burden of manual audit and cleanup. This leads to a critical loss of life cycle control or upgrades of client applications for legacy internal applications or third-party integrations, making it harder to enforce modern security and high-quality data standards at the source. At the same time, it becomes challenging to ensure that only validated, compliant data enters the streaming ecosystem.

CPC Centralized Policy Enforcement helps you enforce encryption, governance, and client behavior policies centrally at CPC Gateway to ensure that only high-quality data meeting your organizational standards flows through the system. This provides a native solution for teams stuck with certain client life cycles outside of their control—such as those using legacy internal apps or third-party integrations—and delivers value across several key areas:

• Enhanced Operational Control: Eliminates the organizational challenge of coordinating with hundreds of application teams for security updates or infrastructure changes. You can remove the need to ping hundreds of app owners for library updates or manual configuration shifts by applying encryption, schema, or routing policies through a single gateway configuration point. 

• Improved Auditability and Compliance: Maintains a consistent protection layer across all data sources, which assists with organizational auditing and helps meet stringent regulatory mandates—such as those in financial services or healthcare—even for the oldest, most complex applications.

• Simplified Client Management: Removes the complexity and cost associated with trying to update or maintain hundreds of legacy client libraries across Java, C#, Python, etc. just to enforce security policies. Applications benefit from granular or full payload encryption transparently with zero changes to existing client application code. 

At EA, CPC supports the following policy enforcement: 

• Gateway Field Level Encryption: CPC Gateway intercepts incoming messages and encrypts/decrypts specific sensitive fields (e.g., personally identifiable information, credit card numbers) before they reach the broker. 

• Gateway Payload Encryption: CPC Gateway encrypts/decrypts the entire message payload, ensuring maximum security for highly regulated data for which no part of the message should be visible at rest on the broker.

• Deep Schema Validation: This capability provides centralized enforcement of schema ID and field level content validation at CPC Gateway to ensure data integrity before it reaches the broker.

Reach out to your Confluent account team to try this feature in our EA program.

Part 3: Pre-Announcing Broker-Native Multi-Tenancy for CPC

We’re excited to showcase a sneak peek of broker-native multi-tenancy for CPC at Current London 2026. This is a much-awaited feature, with EA and GA planned for later this year.

Today, enterprise Kafka teams that self-manage their own infrastructures are trapped by a fundamental trade-off when adding new workloads:

• They can give each team or application its own Dedicated cluster. That provides strong isolation but also creates cluster sprawl. Most clusters run at only 15%–30% capacity; infrastructure costs rise because teams pay for idle headroom, onboarding takes weeks, and every new cluster adds more upgrade, patching, certificate, and incident-response overhead. 

• Or they can consolidate workloads onto shared clusters. That improves infrastructure efficiency—but without native multi-tenancy, it becomes harder to maintain clear tenant boundaries, prevent security or performance interference, and understand which business units are consuming which resources.

CPC’s broker-native multi-tenancy is designed to remove that trade-off by giving each tenant the experience of an isolated Kafka cluster on shared infrastructure, with quotas, observability, and chargeback built in. We’re bringing the same production-ready architecture that powers 30,000+ logical clusters and 8.2 trillion messages per day in Confluent Cloud to your private infrastructure, by introducing logical Kafka cluster (LKC), a virtual Kafka cluster running on a shared physical Kafka cluster (PKC), with full isolation, quota enforcement, and its own endpoint.

Future releases of broker-native multi-tenancy will deliver the following:

• Strict Namespace Isolation: Complete separation of topics, consumer groups, and service accounts to achieve strict namespace isolation

• Granular Quota Enforcement: Granular quotas enforced to guarantee system stability and prevent “noisy neighbor” issues

• Self-Service Onboarding: Role-based access control (RBAC) scoped directly to the LKC, allowing individual admins to self-manage access without burdening the central platform team

• Fine-Grained Observability: Granular metrics, alerts, and views to power individual teams’ operational needs, along with accurate internal chargeback reporting

• Dedicated Endpoints: Unique connection points for each LKC to ensure that your applications can connect to it exactly like they would to a stand-alone physical cluster

Call to Action

Whether you want to quantify the impact on your bottom line or get hands-on with the next generation of private cloud infrastructure, we’re ready to help you eliminate cluster sprawl. Choose your path to engagement: 

• Quantify Your Savings: Contact your Confluent sales or account representative for a personalized estimate of how much CPC can reduce your infrastructure and operational costs. 

• Request EA: Reach out to your Confluent account team to gain access to the EA program for CPC Centralized Policy Enforcement.

• Shape the Future: Join the CPC multi-tenancy design partner and private EA program to get EA and help influence the product before GA. Share your interest here.

Apache®, Apache Kafka®, and the respective logos are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. No endorsement by the Apache Software Foundation is implied by using these marks. All other trademarks are the property of their respective owners.