- Data Streaming
- IBM
What IBM bought when it bought Confluent
Almost everyone equates Confluent with Kafka. Kafka is one of seven pieces, and the other six explain why IBM paid eleven billion dollars.
By Archgents · Published on September 7, 2026 · 6 min read
On 17 March 2026 IBM closed its purchase of Confluent at 31 dollars a share, an enterprise value of about eleven billion dollars. Confluent delisted from Nasdaq and became an IBM subsidiary.
The question we have been asked ever since, in meetings and at the executive breakfast we hosted recently, is almost always the same: if Kafka is open source and free, what exactly did IBM buy?
The short answer is that Kafka is one of seven pieces. The long answer is this article.
Confluent is not Kafka with support
It is the most common confusion and the most expensive one, because it leads you to compare a licence against zero and conclude the obvious.
Kafka solves one problem: holding events in a distributed, ordered, durable log that many consumers can read at their own pace, and reread when they need to. It is the central piece and it is excellent at its job.
But an event backbone in production needs six more things, and those are what a team ends up building by hand when it does not buy them.
The seven pieces
Apache Kafka is the event log. Ordered, durable, partitioned to scale horizontally, with retention that lets you replay history. It is the single source of truth for what is happening right now.
Connectors solve the connection to the real world. Wiring the core, dozens of databases and whichever SaaS is in play into the backbone usually means bespoke code that is fragile and expensive to maintain. Here it is more than a hundred and twenty ready connectors, with native change data capture to read from the core without touching it. Configuration, not development.
Apache Flink processes in flight. Raw events rarely serve on their own: they have to be joined, enriched and computed on at the moment, not in a batch query afterwards. Flink SQL makes that logic declarative and versionable, with results in milliseconds.
Stream Governance is the piece most people underestimate, and the one that decides whether the project reaches production in a regulated institution. Without control, an event backbone turns into a mess of formats that nobody trusts. Here there is a schema registry with versioned contracts, quality rules, end-to-end lineage, encryption and access control.
Tableflow turns streams into Iceberg or Delta tables automatically. Analytics and AI need the same data the business runs on, and duplicating it with an overnight ETL is expensive, slow and leaves the two views out of step. One copy of the data serves both.
Cluster Linking replicates topics between clusters, live. A single cluster is a single point of failure, and hybrid or multi-region setups need the same data available in several places at once. It enables active-active, disaster recovery and the bridge between on-premise and cloud with no ETL in between.
Confluent Intelligence is the newest piece and the one that explains IBM’s interest. An agent hallucinates when it lacks fresh, trustworthy context about the business, and it cannot act on what is happening now. This layer gives the agent live context and lets it execute inside the event stream itself, over governed and traceable data.
How a platform like this matures
Nobody starts at the top layer, and trying to is the most common mistake.
- Integration. Point-to-point connections are replaced by events. The goal is to stop having N systems talking to N systems.
- Event backbone. The log stops belonging to one project and starts belonging to the company.
- Stream processing. Enriching, joining and computing in flight on top of that backbone.
- Context for AI. Agents consume governed, real-time data, and act on it.
Each layer unlocks more use cases and more volume on the same infrastructure. Decoupled microservices, live fraud scoring, customer 360, core modernization through change data capture, risk and exposure computed instantly, personalization at the moment the customer acts. They all run in parallel on the same backbone, without duplicating the platform.
What the platform gains with IBM
IBM’s announcement is clear about its intent: Confluent streams live operational events directly into watsonx.data, so that every model, agent and workflow runs on continuously updated enterprise data. That is the thesis of the purchase, and it lines up with the fourth layer above.
If you already run Confluent, or you are evaluating whether to start, here is what changes in practice.
The platform now has IBM behind it. Eleven billion dollars is a large bet and it is a signal. Confluent stops answering to a quarterly market and becomes part of the data portfolio of a company with decades of enterprise presence, global contracts and support on the ground in the region.
The path to agents gets shorter. The watsonx.data integration is exactly the piece teams used to build by hand: carrying live business context all the way to the model. It now comes with the platform, and it comes governed.
The foundation stays open source. Kafka and Flink are Apache Software Foundation projects. That did not change with the acquisition and it is not going to. The event architecture you design is yours and it stays portable, and no corporate decision locks you in.
Existing contracts run their course. Multi-year agreements run to their term. Renewal is the natural moment to review the joint roadmap, and that is when it helps to sit down with someone who knows both houses.
Product leadership moved up a level. In August 2026 Jay Kreps, co-founder and creator of Kafka, handed the role to Shaun Clowes, until then chief product officer, who is now general manager for Confluent and Data at IBM. That is a good signal: data streaming did not become one more line in the catalogue, it got its own seat in IBM’s data strategy.
Where to start
The acquisition does not change the technical analysis. The seven pieces are the same, the architectural pattern is the same and so are the use cases it unlocks. What changes is that there is more weight behind it now, and a shorter path to agents.
This is how we do it, and it works:
- Assessment. We pick one high-impact use case. One, not a three-year plan.
- Architecture design. We model the solution on the pieces your case actually needs, and no more.
- A governed proof of concept. On Confluent Cloud, in weeks, with schemas and lineage from day one.
We have spent seven years implementing Confluent across Latin America, and today we are IBM partners. It is the same architecture we were building before the deal, now with a bigger partner behind it.
Sources: the closing announcement is on IBM’s newsroom, and the original acquisition announcement is on Confluent’s blog.
The four articles, in one guide you can take with you
We gathered the blog content into a 16-page document: why the nightly batch breaks agents, what IBM bought when it bought Confluent, what changes when the agent runs inside the stream, and how a migration happens without stopping the business.
- All four articles in full, in reading order, with their diagrams
- A four-question checklist before going to production
- Written from seven years implementing Confluent across Latin America
PDF · 16 pages · 508 KB
Fill in your details and the download starts right away.
Done, your download is on its way
If it does not start on its own, use the link below.
Download the PDF guideOther articles
Schedule a free diagnosis call
With one of our senior architects. No sales pitch, just context.