Apache Kafka vs Confluent: What You Actually Get, and What It Locks You Into

The distinction that matters

Apache Kafka is an Apache 2.0 project of the Apache Software Foundation. Confluent Platform is a distribution built by Confluent that includes Apache Kafka and adds components of its own. Those added components are not all under the same licence, and that is the single most important thing to understand before committing to the platform.

Most comparisons present this as "open source Kafka versus the enterprise version". The reality is a three-tier licence structure, and the boundary falls in a place that surprises people.

The component map

The Schema Registry problem

Look at the middle row again. Schema Registry is not Apache 2.0. Neither is ksqlDB.

This is the detail that changes migration scope, and it is consistently missed. Schema Registry is, for most organisations running Avro or Protobuf over Kafka, load-bearing infrastructure. Every producer serialises against it. Every consumer deserialises against it. Schema IDs are embedded in the message payloads themselves. Teams reasonably assume that something so central to how they use Kafka came with Kafka. It did not — it came with Confluent, under Confluent's licence.

The practical consequences: you can keep running it (the Community License permits internal use freely), but you cannot build a competing hosted service on it, and if your organisation requires OSI-approved licences for production components, Schema Registry does not qualify. When you plan a migration off Confluent, Schema Registry is a separate workstream, not a line item.

What Confluent genuinely adds

It would be dishonest to present this as pure lock-in. Several enterprise components solve real problems that Apache Kafka does not solve on its own, and rebuilding them is not trivial.

• Tiered Storage — offloads older log segments to object storage. Apache Kafka now has its own tiered storage (KIP-405), but Confluent's implementation is older and more battle-tested. For long-retention workloads this materially changes cost.
• Cluster Linking — replication between clusters without a separate Connect pipeline. The open alternative is MirrorMaker 2, which works but requires more operational care.
• RBAC and audit logs — Apache Kafka ships ACLs. Role-based access control across the whole platform, with structured audit logging, is a Confluent addition, and it is usually what satisfies an auditor.
• Control Center — a management UI. Good open alternatives exist, which makes this the easiest piece to replace.
• Self-Balancing Clusters — automatic partition rebalancing. The open equivalent is Cruise Control, which is capable but is another system to run.

If you are using several of these deeply, "just run Apache Kafka" understates the work, and anyone telling you otherwise has not done the migration.

The honest decision framework

Three questions settle it for most organisations.

1. Which enterprise components are you actually using?

Audit rather than assume. A surprising number of Confluent Platform deployments use Kafka, Schema Registry and Control Center, and nothing else licensed. Kafka is Apache 2.0. Schema Registry keeps working. Control Center is replaceable. That estate has a much shorter path off the platform than its licence bill suggests.

The estates that are genuinely embedded are the ones using Cluster Linking for multi-region topology, RBAC for compliance, and Tiered Storage for retention economics. Those are three real projects.

2. What is the cost trajectory?

Confluent pricing scales with throughput and cluster count. The complaint we hear most is not the absolute number but its slope: costs that track data growth rather than business value, on a platform where the expensive components are the ones that are hardest to remove.

3. Who operates it after you leave?

This is where most exits stall. Confluent is not only software, it is an operational safety net. Teams that migrate to Apache Kafka and do not replace that capability discover the gap during their first partition-leader election under load at 3am.

Running Apache Kafka well needs real expertise in broker configuration, partition strategy, consumer group behaviour, the coordination layer, and the upgrade path. The migration is not finished when the brokers are running; it is finished when someone owns them.

The path off, if you take it

A migration that works, in the order it works in:

1. Inventory the licence boundary. Every component, which of the three licences it sits under, and whether you use it. This alone often shrinks the project.
2. Replace Control Center first. Lowest risk, immediate licence relief, builds confidence.
3. Keep Schema Registry running. The Community License permits it. Do not couple a schema migration to a platform migration; they are independent and doing both at once is how outages happen.
4. Substitute the enterprise components you genuinely use. MirrorMaker 2 for Cluster Linking, Cruise Control for Self-Balancing, KIP-405 tiered storage where your Kafka version supports it, Kafka ACLs plus your existing identity provider for RBAC.
5. Move the brokers last, and only once the operational capability exists.

We wrote the longer version of this as Confluent alternatives: running Apache Kafka without the platform.

Confluent alternatives for self-managed Apache Kafka

The products sold as Confluent alternatives are not alike. Some run Apache Kafka for you, some reimplement the Kafka protocol, and some support the Apache Kafka you already run. The useful way to sort them is by who operates the brokers and whose code is on them.

• Managed Apache Kafka services. Amazon MSK manages Apache Kafka infrastructure and operations inside AWS. It takes broker operations off your team, and with them the self-managed deployment.
• Kubernetes operators. Strimzi runs Apache Kafka clusters on Kubernetes. It is a CNCF project, accepted in August 2019 and at the Incubating level since February 2024. It automates deployment and configuration; it is software, not a support contract.
• Kafka-compatible engines. Redpanda is a streaming engine written in C++ that ships as a single binary and states that it is compatible with the Kafka API. It is a different codebase from Apache Kafka, so moving to it is a platform migration, not an upgrade.
• Upstream Apache Kafka with commercial support. You keep the Apache distribution on your own infrastructure and buy the patching and operational cover separately. OSSeva does this: Patch ships signed builds with backported CVE fixes for Kafka lines the project no longer patches, Assure adds compliance attestation and VEX statements, and Operate adds 24/7 managed operations with a 15-minute P1 response. Because the brokers stay on Apache Kafka, leaving later is an ordinary upgrade.

For a self-managed estate leaving Confluent Platform, the last option changes the least: the same brokers, the same clients and the same ZooKeeper or KRaft topology. The OSSeva and Confluent comparison sets out where each is stronger, and leaving Confluent covers the migration order.

The version question underneath all of this

One thing neither Apache Kafka nor Confluent solves: the Apache Kafka project maintains a small number of recent release lines. If your brokers are on an older 3.x line — and many Confluent Platform deployments are pinned well behind, because the platform version gates the Kafka version — you receive no upstream security fixes regardless of which side of this comparison you land on.

That is worth resolving independently of the platform decision. OSSeva patches EOL Kafka lines, and the ZooKeeper ensembles behind pre-KRaft clusters, which in most estates are older than the brokers they coordinate.

Related reading

• Confluent alternatives: running Apache Kafka without the platform
• Apache Kafka extended support
• Apache ZooKeeper extended support