Confluent alternatives after the IBM acquisition: how to choose
The realistic alternatives to Confluent are self-managed Apache Kafka, Strimzi, Amazon MSK, Aiven for Apache Kafka, NetApp Instaclustr, Redpanda and StreamNative Kafka Service. Choose by Kafka API compatibility, operator, Schema Registry and Connect replacements, access control, cost model and migration path. The Confluent components a team depends on narrow the shortlist more than broker performance does.
Status as of 5 October 2026: IBM completed its acquisition of Confluent on 17 March 2026, buying all issued and outstanding common shares for $31 per share in cash, an enterprise value of approximately $11 billion, according to IBM’s announcement. For a regulated firm, that is a reason to re-examine concentration: which parts of the streaming stack come from one supplier, and which parts the organisation controls itself. Factor House covers the deal itself in what the IBM and Confluent deal means for Kafka users.
Where this page gives my own view it says so, and that view comes from production experience with Kafka rather than from any vendor’s documentation. The first of those views I set out in a LinkedIn post on the deal: understand your vendor exposure and dependencies even if you have no immediate need to migrate. Work out where the platform relies on Confluent-specific features as against standard Kafka APIs, with Schema Registry and Kafka Admin among the things to classify, across CI/CD, data pipelines, monitoring and operational workflows, then evaluate what a move to a provider such as Amazon MSK, Redpanda or Aiven would involve.
Two names often appear on alternative lists and are left out of the comparison. WarpStream is a Confluent product: Confluent announced it had acquired WarpStream in September 2024, so a move to WarpStream does not leave the vendor that IBM now owns. On 8 May 2026 Buf announced that CoreWeave had acquired Bufstream, its Apache Kafka-compatible streaming platform, and added it to CoreWeave’s internal platform as part of the W&B Models and Weave product lines; confirm current availability with the vendor before shortlisting it. Factor House is not on the list either. Kpow (a Kafka UI and management tool) and Flex (for Apache Flink) are not Kafka platforms. They run on top of whichever platform a team chooses, which is covered in what stays the same.
The alternatives compared
Every cell below comes from the vendor’s or project’s own documentation, linked in the sources by option under the tables. Where a vendor does not publish a fact, the cell says so rather than guessing.
| Option | Kafka API | Who operates it | Cost model as published |
|---|---|---|---|
| Self-managed Apache Kafka | Is Apache Kafka | The team | No licence fee. Infrastructure and staff time |
| Strimzi on Kubernetes | Runs Apache Kafka | The team, through Kubernetes operators | No licence fee (Apache 2.0). Cluster and staff time |
| Amazon MSK | Runs Apache Kafka | AWS runs the brokers | Hourly rate per broker instance plus storage |
| Aiven for Apache Kafka | Runs Apache Kafka | Aiven, in the cloud the customer picks | Hourly rate per service, invoiced monthly |
| NetApp Instaclustr | Runs Apache Kafka | NetApp Instaclustr | Per node, priced monthly. Price covers management only for bring your own cloud |
| Redpanda | Kafka protocol compatible, with documented exceptions | The team (self-managed) or Redpanda (Cloud, bring your own cloud) | Community Edition free. Enterprise Edition needs a licence key. Cloud: pay as you go or annual commit |
| StreamNative Kafka Service | Native Apache Kafka on the Ursa Engine. Kafka clusters listed as Public Preview | StreamNative | Pricing page lists StreamNative Cloud from $73 a month (Serverless) and $505 a month (Dedicated). Serverless Kafka is Private Preview |
| Option | Schema registry | Kafka Connect | Access control | Migration path in the docs |
|---|---|---|---|---|
| Self-managed Apache Kafka | Bring one: Apicurio or Karapace | Ships with Apache Kafka | Kafka ACLs | MirrorMaker 2 |
| Strimzi on Kubernetes | Separate deployment | KafkaConnect resources | TLS, SCRAM-SHA and OAuth authentication; Kafka ACLs | MirrorMaker 2 |
| Amazon MSK | AWS Glue Schema Registry | MSK Connect (Kafka Connect 2.7.1 or 3.7.x) | IAM access control | MSK Replicator, including from self-managed Kafka |
| Aiven for Apache Kafka | Karapace | Managed Kafka Connect | Aiven ACLs or Kafka-native ACLs | Managed MirrorMaker 2 |
| NetApp Instaclustr | Karapace add-on | Managed Kafka Connect | Kafka users and ACLs | Managed MirrorMaker 2 |
| Redpanda | Built into the broker binary | Redpanda Connect, and Kafka Connect | Kafka ACLs. RBAC needs an enterprise licence | Shadowing (enterprise licence), from any Kafka API-compatible cluster |
| StreamNative Kafka Service | Subset of the Confluent Schema Registry API | Existing connectors documented to work unchanged | OAuth 2.0 or API keys; topic-level ACLs | Universal Linking: topics, consumer group offsets and schemas |
Sources by option
- Apache Kafka: Apache Kafka licence, Apache 2.0, Confluent licensing FAQ, Apicurio Registry, Karapace, Apache Kafka geo-replication.
- Strimzi: project site, overview, licence.
- Amazon MSK: pricing, AWS Glue Schema Registry, MSK Connect (Kafka Connect versions as listed on 5 October 2026), IAM access control, MSK Replicator.
- Aiven for Apache Kafka: pricing, Karapace on Aiven, Kafka Connect, ACLs.
- NetApp Instaclustr: pricing, managed Kafka, Karapace add-on.
- Redpanda: Kafka compatibility, Schema Registry, licensing, RBAC, Shadowing, pricing.
- StreamNative Kafka Service: Kafka Service overview, Kafka clusters compared with KSN, migration guide, Confluent Schema Registry compatibility, pricing.
How to choose
- List Confluent dependencies first. Schema Registry, each connector with its licence, ksqlDB queries, RBAC, audit logs and Cluster Linking. Anything under the Enterprise License needs a named replacement.
- Decide who operates the brokers. If the team does not want on-call for Kafka, the shortlist is Amazon MSK, Aiven for Apache Kafka, NetApp Instaclustr, managed Redpanda and StreamNative Kafka Service. If it does, self-managed Apache Kafka, Strimzi or self-managed Redpanda.
- Match the cloud and the identity model. An AWS-only estate that already governs access with IAM fits Amazon MSK. A multi-cloud estate fits a provider that runs in several clouds.
- Test protocol and registry compatibility. Run the real client libraries and the real serializers against a proof-of-concept cluster, particularly for Redpanda, StreamNative Kafka Service and any non-Confluent registry.
- Plan the move. Pick the replication path the target documents: MirrorMaker 2, MSK Replicator, Redpanda Shadowing (enterprise licence) or StreamNative Universal Linking. Keep one management view across both clusters until cutover.
One thing I would add to step 2, which I learned the hard way: managed services also need monitoring, because Kafka health is a shared responsibility. Confluent, AWS and Aiven all do a great job of hosting Kafka, but they are not responsible for how you write your client code, and the way you write your client code can greatly affect cluster health. They cannot tell you what they do not know; only you can know that. I made that case in the June 2026 Factor House webinar on Kafka operational issues.
The IBM-Confluent acquisition has sent a signal through the data streaming market that every enterprise architect is processing: consolidation is here, and your tooling dependencies matter. … The question of who controls your streaming infrastructure has moved from theoretical to urgent.
Derek Troy-West, Co-founder and CEO of Factor House
Budget pressure is pushing more teams to rethink their Kafka setup; AI spend for some, general cost-cutting for others.
Chad Harris, Solutions Architect at Factor House
What each option means in practice
Self-managed Apache Kafka
Self-managed Apache Kafka keeps everything Apache 2.0. Confluent’s own licensing FAQ lists Apache Kafka, with Connect and Streams, under the Apache 2.0 licence. The cost is operational: the team runs brokers, upgrades, a schema registry and a Connect cluster, and owns every incident.
Strimzi
Strimzi is the same Apache Kafka, run on Kubernetes by operators. The project’s overview describes a Cluster Operator, Topic Operator and User Operator, with Kafka Connect, MirrorMaker 2 and an HTTP Bridge as managed components. It suits a team that already runs Kubernetes well. It does not take the on-call burden away.
Amazon MSK
Amazon MSK hands broker operations to AWS. MSK Connect uses the open-source Kafka Connect framework, the registry is AWS Glue Schema Registry (Avro, JSON Schema and Protobuf), and IAM access control handles authentication and authorization in one mechanism. That last point is a governance decision: access rules move into IAM policies rather than Kafka ACLs.
My own experience is that MSK does what it is meant to do, and that is why every change still has to be verified. On one cluster we raised provisioned storage throughput, following the vendor recommendation, and increased the replica fetcher and I/O thread counts to match. The cluster upgrade failed mid-process and MSK rolled it back automatically, as designed. The provisioned storage throughput stayed unchanged, but the fetcher and I/O thread counts we had increased did not revert, and the cluster ran fine for six months until a single disk failed on one broker. We had forgotten to check that the configuration increase had not also rolled back. As I put it in the June 2026 webinar, “a rollback isn’t done until every change is verified and reverted.” And “config drift is generally silent until it isn’t.” After any rollback on a managed platform, diff the running broker config against your baseline.
Aiven for Apache Kafka and NetApp Instaclustr
Both run Apache Kafka as a managed service and both offer Karapace, an open-source registry, in place of Confluent Schema Registry. Aiven documents two ACL models, its own simplified topic-level ACLs and Kafka-native ACLs. NetApp Instaclustr notes that its Karapace add-on cannot be enabled alongside its older Kafka Schema Registry add-on, so registry choice is made per cluster. On availability, NetApp Instaclustr’s managed Kafka page states a 99.99% SLA on standard deployments and 99.999% on enterprise deployments with dedicated ZooKeeper or KRaft nodes.
Redpanda
Redpanda is a separate implementation of the Kafka protocol, not Apache Kafka. Its compatibility page lists exceptions, including one SCRAM mechanism per user, no support for the request_percentage quota and no implementation of the server-side part of KIP-890. In practice, the quota exception matters to a team that caps clients by share of broker request time, since Redpanda offers byte-rate and topic-mutation quotas instead. On KIP-890, Redpanda states that its own transactions implementation is not susceptible to the class of errors that KIP addresses. Its registry is built into the broker binary, and RBAC requires an enterprise licence.
Redpanda’s docs describe Shadowing as enterprise-grade disaster recovery: asynchronous, offset-preserving replication from a source cluster that can be another Redpanda cluster or any Kafka API-compatible cluster, such as Apache Kafka, Confluent Cloud or Confluent Platform. The overview states that the feature requires an enterprise licence. The docs frame it as disaster recovery rather than as a migration tool, so a team considering it for a cutover should prove that use in a test first.
StreamNative Kafka Service
StreamNative’s documentation describes Kafka Service as a fully managed, native Apache Kafka service on the Ursa Engine that is “not a Kafka compatibility layer”, with existing Kafka clients, Kafka Connect connectors and Kafka Streams applications documented to work without code changes. Two limits matter for a decision. The comparison page lists Kafka clusters as Public Preview, and Serverless Kafka as Private Preview. The Schema Registry implements a subset of the Confluent API: its compatibility reference lists endpoints that return 404, so test every registry call the clients make. StreamNative Cloud also offers Kafka compatibility on Pulsar clusters, a separate product that is not what this page covers.
What to check before you leave Confluent
The broker is rarely the hard part. The components around it are, because several of them are not Apache Kafka at all.
Schema Registry
Schema Registry is a Confluent product, not part of Apache Kafka. Confluent’s licensing FAQ puts Schema Registry, REST Proxy and ksqlDB under the Confluent Community License, which bars offering them as a competing hosted service. The mature alternatives are Apicurio, AWS Glue Schema Registry and Karapace. Moving means client serializer configuration changes and compatibility testing, not a copy of the schemas topic.
Compatible registries differ at the edges
A registry that exposes the Confluent REST API can still miss features. WarpStream’s BYOC Schema Registry documentation, for example, says it is API-compatible with Confluent’s Schema Registry but does not support data contracts or client-side field level encryption. Test every endpoint and feature the clients use, against the target registry, before cutover.
Connectors are a licensing question
The Kafka Connect framework is Apache 2.0 and portable. Individual connectors are not always. Confluent’s Amazon S3 sink connector is available under the Confluent Community License, and the licensing FAQ lists commercial and premium connectors under the Confluent Enterprise License. List every connector in production with its licence, and find an Apache 2.0 or target-platform equivalent for each one that cannot move.
Managed connectors carry their own limits
Confluent Cloud’s fully managed connectors have a limits page of their own; one example is that additional connector properties can be set only through the Confluent REST API and CLI, not the Cloud Console. Automation built around those limits will need rework on a self-managed or other managed Connect cluster, where the controls are different.
ksqlDB
ksqlDB is under the Confluent Community License, like Schema Registry. Queries written for it have to be re-hosted or rewritten after a move, so size that work separately from the broker move. Apache Flink SQL and Kafka Streams are two engines to evaluate for a rewrite.
RBAC, audit and cluster linking
The licensing FAQ lists Role-Based Access Control, Structured Audit Logs, Cluster Linking, Tiered Storage and Control Center under the Confluent Enterprise License. If governance depends on any of them, the target platform needs an answer for each: IAM on Amazon MSK, enterprise-licensed RBAC on Redpanda, ACL models on Aiven, or a governance layer on top.
Storage architecture
Diskless and object-storage Kafka changes what replication means. WarpStream’s architecture documentation describes agents that stream data directly to object storage instead of replicating it between brokers across availability zones, so replication-factor choices and replica views do not carry the same meaning there. Check which storage type each topic, and each tool’s internal topics, ends up on.
Client libraries
A Kafka API compatible platform still has to meet your client code, so list which client libraries the estate uses before testing against a new platform. My view, from the June 2026 webinar: use the official Apache Kafka or Confluent client libraries, and if you are not on the JVM, use a library that wraps librdkafka rather than one that reimplements the Kafka protocol itself. Differences in protocol interpretation between third-party client implementations cause horrific problems, and quiet ones that compound. One case involved a message header that should have written four bytes but wrote three, which looked harmless until an official client started rebalancing whenever it encountered those messages.
Message size limits
I have had so many teams ask for a message size exception: they promise it will be fine, it is a low throughput topic. Then six months later the topic becomes popular, and because the messages are so big you cannot get much throughput, and there is really no fix for that. As I said in the June 2026 webinar, “Kafka is a phenomenal messaging tool and it can do millions and billions of messages a second if those messages are small. It does not like big messages.” So keep messages small and do not apply for extensions, on any platform. The limits also differ by provider and cluster type, which matters if a topic already relies on large messages: Confluent Cloud’s cluster types page lists a message size of 8 MB for Basic and Standard clusters and 20 MB for Enterprise, Dedicated and Freight clusters, Amazon MSK’s quotas page lists a maximum message size of 8 MiB for MSK Serverless, and on MSK Provisioned message.max.bytes is a configurable broker property.
Contract and exit terms
Review renewal dates, notice periods, committed spend and data export terms before setting a migration timeline. This is a general prompt to read the contract with the right people, not legal advice.
What stays the same after a move
The platform changes. The day-to-day work of inspecting topics, managing consumer groups, reviewing ACLs and checking schemas does not. If that work runs through a provider’s own console, a platform migration also means retraining every engineer on a new interface. A management layer that is independent of the platform keeps that part constant.
Kpow is that kind of layer: a self-hosted Kafka UI and management tool that connects to the clusters directly, whichever platform hosts them. Factor House publishes integration guides for these platforms.
Options compared on this page:
- Self-managed Apache Kafka
- Strimzi
- Amazon MSK
- Aiven for Apache Kafka
- NetApp Instaclustr
- Redpanda
- StreamNative Kafka Service
Running alongside during a migration:
- Confluent Cloud, for the period when both platforms run side by side
- WarpStream, a Confluent product, listed for completeness
During a migration, one view across the old and new clusters keeps the side-by-side period observable. For teams running Apache Flink alongside Kafka, Flex plays the same role for Flink jobs.
FAQ
What is the best alternative to Confluent?
There is no single best one. Self-managed Apache Kafka fits teams that want full control and accept full operations. Strimzi fits teams that run Kubernetes and want to stay on Apache 2.0. Amazon MSK fits AWS-centred teams that want AWS to run the brokers. Aiven for Apache Kafka and NetApp Instaclustr fit teams that want managed Apache Kafka with an open-source registry. Redpanda fits teams that accept a separate Kafka-protocol implementation for its built-in registry, with some features behind an enterprise licence. StreamNative Kafka Service fits teams that want a managed, native Apache Kafka service and can accept that its Kafka clusters are listed as Public Preview, pending a proof of concept.
Is Confluent owned by IBM now?
Yes. IBM completed the acquisition on 17 March 2026, at $31 per share in cash and an enterprise value of approximately $11 billion, per IBM’s announcement. WarpStream, which Confluent acquired in 2024, is part of the same business.
Is Confluent Schema Registry open source?
No. Confluent’s licensing FAQ lists Schema Registry under the Confluent Community License, not Apache 2.0. Karapace and Apicurio are open-source alternatives, and AWS Glue Schema Registry is the managed option on AWS.
Can Kafka Connect be used without Confluent?
Yes. Kafka Connect is part of Apache Kafka under Apache 2.0, and Amazon MSK, Aiven, NetApp Instaclustr and Strimzi all run it. Individual connectors are the catch: some of Confluent’s are under the Confluent Community License or the Confluent Enterprise License and need a replacement.
Is Redpanda a drop-in replacement for Kafka?
For most clients it works unchanged, but not every feature matches. Redpanda’s documentation lists compatibility exceptions, including one SCRAM mechanism per user and no support for the request_percentage quota. Test the clients and features in use.
What replaces ksqlDB?
ksqlDB is a Confluent product under the Confluent Community License. Queries written for it have to be re-hosted or rewritten after a move. Apache Flink SQL and Kafka Streams are two engines to evaluate, and the work should be budgeted separately from the broker move.
Does the Kafka management tool have to change with the platform?
Not if it is independent of the platform. A self-hosted tool such as Kpow connects to clusters directly. The Kpow features page lists compatibility with self-managed Kafka, Amazon MSK, Redpanda, NetApp Instaclustr and Aiven, among others, and Factor House publishes integration guides for Strimzi and StreamNative Kafka Service, so the team can keep the same interface through and after a migration.