I think a subset of customers still sees Confluent as plumbing, the pipes that carry data on its way to somewhere else. Confluent’s news at Current 2026 in San Francisco is the strongest argument against that view I’ve seen, and it comes under eight months after IBM closed its acquisition. Confluent introduced its Streamhouse architecture and a way to query live data right on its own platform. A Streamhouse is designed to provide applications, analytics, and AI agents with a real-time view of the business. Confluent says getting that view requires an architecture that’s always current, decentralized across existing systems, and mission-critical. It uses an airline example to show what can go wrong without that real-time view. When flight operations, scheduling, and reservations systems update at different times, a rebooking agent can book a seat on a connection the aircraft can’t make.
Lightning Tables could mean one less database next to Kafka
Lightning Tables lets you query live data. It’s now on AWS, and it keeps read-only tables up to date from Kafka data. Applications access those tables via SQL or an API. And agents get to them through the Model Context Protocol (MCP). In Confluent’s internal testing, new data was ready to serve in under a second. With that kind of speed, teams shouldn’t have to copy a stream into a separate database and keep the copy in sync just to query it.
I love that consolidation story, at least in the narrow sense of one less database to run and keep in sync. I don’t think a company gets to one view of its business by moving everything onto one platform. But dropping one side database is a much smaller ask. It’s also an easier budget conversation than a brand-new agent project. If I were just starting out, I’d start with something like current-state lookups, such as where an order or a shipment stands. I would run those queries against one table at a time. So if I wanted customers and orders combined, I’d build that view upstream in Flink, knowing that’s the stream processing engine in Confluent’s platform. Building the view in Flink also aligns with Confluent’s case for shaping data close to the source, so other systems don’t each have to rebuild it.
I’m also glad Lightning Tables is read-only. Confluent says operational applications and databases still handle transactions, so a business’s data keeps living across a lot of different systems. No architecture keeps all of those systems perfectly synchronized, but Confluent says a Streamhouse cuts down on conflicting answers, and I like that realistic framing.
Query rounds out what Confluent can serve
Lightning Tables also rounds out Query, the new fifth pillar of Confluent’s platform alongside Stream, Connect, Process, and Govern. Query covers how Confluent gets current data to whoever needs it. Tableflow hands streams to lakehouses as open tables, the Real-Time Context Engine feeds agents over MCP, and Lightning Tables lets applications query current state directly. Confluent already had the first two, so I think Lightning Tables helps hold the pillar together.
Outside of Lightning Tables, the Streamhouse looks a lot like what Confluent was already delivering. And Confluent isn’t hiding it. If anything, Streamhouse finally puts a name on something companies have been doing for years, and Lightning Tables is the new product Confluent needed to serve it directly. It’s cool hearing customers such as Extend, an AI-native commerce platform, already saying its Streamhouse setup turns Kafka into its operational source of truth.
A faster stream won’t help if a schema change breaks it
Serving data faster doesn’t help much if someone changes the data’s structure and breaks everything downstream. Something as small as renaming a column has been causing that headache for as long as I can remember. So I’m a fan of Schema Registry’s new compatibility policy, which Confluent says catches a breaking change before it gets to Flink, Tableflow, or Lightning Tables. When a dashboard breaks, somebody loses a morning fixing it. But when agents are making decisions off that same bad data, it could be a while before anyone notices, and I think that’s a much bigger deal. So as fast as streaming data is getting, trust still feels like the harder problem to me.
Granite and the mainframe look like early payoffs from the IBM deal
The IBM deal shows up most clearly in Granite, and I like this one a lot because it brings IBM’s models right into the Confluent product. Confluent is adding three Granite Time Series models to Flink on its self-managed platform, so teams can run forecasting and anomaly detection with SQL. Confluent says those models don’t need pre-training, run on CPUs alone, and keep data inside the customer’s environment. I’d expect that setup to appeal to a regulated company that won’t send its data to an outside model.
Regulated companies are also where IBM’s reach should count. Confluent says IBM extends the Streamhouse further into mainframes, enterprise databases, and hybrid environments. Many critical transactions still run on IBM Z, IBM’s mainframe platform. I don’t see how an agent can act on current state it can’t see, so I’d expect that reach to be one of the biggest things IBM brings.
Confluent’s role at IBM also goes beyond the data business. IBM is assembling an open AI stack for hybrid environments, with Confluent meant to give it a live view of the business. IBM’s Red Hat and HashiCorp cover the infrastructure agents run on, while IBM Bob and watsonx Orchestrate cover building and managing those agents. I like seeing all of those products in one strategy. Seeing them together raises the bar quite a bit, and it puts the onus on IBM to keep connecting all of them publicly and to do it more.
Confluent already integrates with IBM’s watsonx.data lakehouse
One connection already in place is with IBM watsonx.data, IBM’s own open lakehouse. It was a day-one integration when IBM closed the deal. IBM’s lakehouse can query Tableflow’s Iceberg tables without making another copy. That connection aligns with Confluent’s view that a Streamhouse works alongside lakehouses, which continue to handle historical analysis, exploration, and model training.
I also like that Confluent stays open here, since Tableflow syncs with other vendors’ catalogs. That openness is huge for a customer who already picked a lakehouse. IBM’s own customers will still want to know how these pieces fit together, and I’d love to see IBM show them a worked example. I’m thinking a bit out loud here, but it could be something like a bank streaming mainframe transactions into Confluent and running Granite models in the stream. That bank could keep its history in watsonx.data and hand results to a watsonx Orchestrate agent.
Confluent is moving from pipeline to serving with IBM behind it
Coming into Current, I’d call Confluent a leader in data streaming, and this news opens up a newer market for it. To me, that newer market is the current-state lookup work that teams handle today with the separate databases and caches they run alongside Kafka. Anyone can use the Streamhouse name, so it won’t decide who wins that work. I expect that work to go to the vendor that lets a customer do the most without adding another system and reaches furthest into what’s already running. IBM gives Confluent a lot to work with in terms of reach.
Reach is also where I’d push Confluent next. I expect agents to run wherever the work happens, including inside a bank’s own data center. A round trip through someone else’s cloud won’t make much sense there. I want to see Lightning Tables reach the self-managed deployments I expect many regulated IBM customers to run. Confluent also says broader business semantics are still to come. I’m glad to hear it, because an agent needs to know what an order status means and what it is right now. I’m curious, too, who ends up owning the Streamhouse budget: the data platform team that runs the lakehouse or the AI team building agents.
Confluent left Current with a better answer for anyone who still calls it plumbing, since it can now serve applications directly as well as move data. IBM also has something concrete to point to when it explains why Confluent matters to its AI strategy.
