What the IBM-Confluent deal means for Kafka users

Connect Amazon MSK, Confluent, Redpanda and self-managed Kafka from a single Kpow instance, with no proxy and no vendor lock-in.

Summarize with AI

Prefer Factor House in Google

On March 17, 2026, IBM completed its $11 billion acquisition of Confluent. The deal was announced in December and closed quickly. Since then, the question for anyone running Kafka in production has been straightforward: what changes, and what should Kafka teams do about it?

Status as of October 5, 2026: the acquisition is complete. IBM closed its purchase of Confluent on March 17, 2026, according to IBM’s completion announcement.

No longer pending: IBM has already acquired Confluent. The two companies announced a definitive agreement on December 8, 2025, with closing then expected by the middle of 2026 and subject to Confluent shareholder approval and regulatory approvals (IBM announcement).

IBM paid $31 per share in cash for all issued and outstanding Confluent common shares, an enterprise value of approximately $11 billion (IBM completion release). IBM said at announcement that the purchase would be funded with available cash on hand (IBM announcement).

IBM acquired Confluent to feed real-time, trusted data to enterprise AI models, agents and automated workflows across on-premises and hybrid cloud environments, which IBM describes as a smart data platform (IBM completion release). According to IBM’s announcement, the deal fits its hybrid cloud and AI strategy, complements its Data and Automation portfolio, and follows its earlier open-source acquisitions of Red Hat and HashiCorp.

Confluent gives IBM a data streaming platform built on Apache Kafka, which IBM’s completion release says more than 6,500 enterprises, including 40% of the Fortune 500, rely on. IBM announced four day-one integrations in that release:

IBM’s deal announcement lists Confluent Cloud, Confluent Platform, WarpStream and Confluent Private Cloud as Confluent’s deployment options.

The early signs are not reassuring. Hundreds of former Confluent employees have appeared on LinkedIn with #opentowork since the acquisition closed. Unofficial reports suggest the number may be as high as 800. There’s been no official statement from IBM or Confluent on the scale of the cuts.

For engineering and platform teams, the concern isn’t the layoffs themselves but what they imply about product velocity. Confluent’s value has always been driven by deep engineering investment: in the Kafka core, in the connector ecosystem, in Schema Registry, in the cloud platform. Fewer engineers means slower bug fixes, slower feature development, and less community engagement on KIPs. If you depend on Confluent’s managed connectors or cloud-native features, the pace at which those improve is directly relevant to your operational risk.

On August 13, 2026, Jay Kreps, Confluent’s co-founder and CEO, announced he was stepping back from the role after almost 12 years, handing the position to Shaun Clowes, the company’s chief product officer, in a post on X. Kreps founded Confluent in 2014 with Neha Narkhede and Jun Rao, the team that built Kafka at LinkedIn, and had run the company since.

This sits alongside the workforce changes described above as another signal worth tracking. A founder and CEO leaving a few months after an acquisition closes is a major change, and it’s reasonable to ask what it means for product direction going forward.

Clowes has been part of the business since December 2022, when he joined as chief product officer, so the handover isn’t to someone unfamiliar with Confluent’s product and engineering priorities. That continuity is worth weighing against the scale of the change, particularly as the integration into IBM continues to play out.

Two precedents are worth studying, though neither is a perfect analogy.

The first is Oracle’s acquisition of Sun Microsystems in 2010, which brought MySQL into Oracle’s hands. Over time the open-source release cadence slowed, and most Linux distributions switched their default database to MariaDB. Oracle never killed MySQL, but it deprioritised it. The key difference: Oracle’s core business (Oracle Database) competed directly with MySQL, giving Oracle an incentive to let it stagnate. IBM has no equivalent competing product, so the incentive structure is different.

The more instructive precedent is Red Hat’s decision, under IBM ownership, to replace CentOS Linux with CentOS Stream in late 2020. CentOS had been a free, stable, binary-compatible rebuild of RHEL. Thousands of organisations ran production workloads on it precisely because it tracked a stable RHEL release. CentOS Stream changed the model to a rolling preview of the next RHEL version. The product still existed, but the contract it had with its users (stability equivalent to RHEL) was broken. Organisations that had standardised on CentOS faced a forced migration they hadn’t planned for.

The pattern in both cases is the same: the open-source project survived, but the terms of engagement changed in ways that imposed real costs on users who had built deep operational dependencies.

Apache Kafka the open-source project is likely safe. It has multiple companies invested in its development. AWS, Redpanda, Aiven, and others all have commercial interests in the Kafka protocol continuing to thrive. IBM’s own announcement frames the deal as a continuation of its open-source investment, building on its Red Hat and HashiCorp acquisitions (IBM announcement).

The risk is in the commercial and proprietary layer. Specifically:

Confluent-managed connectors. If your data pipelines use Confluent’s fully managed or licensed source and sink connectors, you have a hard dependency. There’s no direct equivalent on other platforms. The open-source Kafka Connect framework is portable, but the managed hosting and operational wrapper around it is not.

Schema Registry. Confluent Schema Registry is the de facto standard for schema management in Kafka environments, but it’s a Confluent product, not part of Apache Kafka. Alternative implementations exist (Apicurio Registry from Red Hat and AWS Glue Schema Registry being the most mature) but migration involves changing client configurations, compatibility testing, and potentially reworking CI/CD pipelines that integrate with the registry API.

Confluent Cloud platform dependencies. Features like cluster linking, Stream Governance, the Confluent Terraform provider, and the Confluent CLI tooling don’t have 1:1 replacements in the broader ecosystem. If your operational workflows are built around these, a migration is materially harder than “just point at a different broker.”

Pricing and licensing. This is the quietest risk but potentially the most impactful. IBM has a well-established pattern of monetising enterprise customers through licensing changes. Confluent’s current pricing may not survive contact with IBM’s enterprise sales model.

You don’t need to migrate anything today. But you should know your exposure. A few concrete questions worth putting to your platform team:

That last point is sometimes overlooked. If your engineers’ daily Kafka workflows (topic inspection, consumer group management, ACL configuration, data inspection) run through Confluent tooling, that’s both a technical dependency and a familiarity dependency. It’s one of the things that makes a provider migration feel harder than it technically is.

This is an area where decoupling is straightforward. Vendor-agnostic Kafka management tools exist specifically to work across providers. Factor House’s Kpow, for example, works with Confluent Cloud, AWS MSK, Redpanda, Aiven, and self-managed Kafka. Regardless of which tool you choose, the underlying point is the same: building your observability and operational workflows on a tool that is independent of your Kafka provider means one less thing to migrate if your provider changes.

If the answer to the second question is “a lot”, the vendor-neutral guide to Confluent alternatives after the IBM acquisition compares the managed and self-hosted options and the migration work each one implies.

A few signals that will indicate how this acquisition is playing out over the coming months:

None of this is cause for panic. But the cost of understanding your dependencies now is low, and the cost of discovering them under pressure is high.

For the fundamentals behind this, see the complete guide to Kafka.