Hours old is the new wrong.

StreamHouse, the streaming lakehouse, and why real-time data architecture suddenly has a name.

A category just got a name

On 15 September 2026, five companies that compete hard with each other put out a joint announcement. Aiven, Confluent, Redpanda, StreamNative and Ververica formed the Streamhouse Working Group. They didn’t launch a product. They published a definition. The group keeps the spec in a public repo, works on the open standards under it, and lets anyone use the name for free under a binding trademark commitment. No single vendor owns it.

The definition itself is one line. A Streamhouse captures, transports, transforms, governs and serves the current state of your business continuously, so applications and agents can act on it. Three things make it one. Real-time: data updates as events happen, not overnight. Production-native: it runs at production service levels, because real things depend on it. Decentralized: it works with data where it already sits, instead of insisting everything move to one place first. That last one is the break from the past. We spent a decade building the opposite.

Why IBM and Confluent matter here

Six months earlier, IBM closed its acquisition of Confluent. $31 a share. Roughly $11 billion. Done on 17 March 2026. That is a very large cheque for a streaming company. It tells you where IBM thinks the bottleneck is. Rob Thomas said it plainly: clients need trusted data moving continuously across the business so their models and agents act on what is happening now, not on data that is hours old. Look at the day-one integrations and the shape is obvious. Confluent feeds live events into watsonx.data, IBM’s lakehouse. It streams transaction data off IBM Z. It plugs into MQ and webMethods. Streaming on one side. Lakehouse on the other. One governed path in between. That is a Streamhouse, bought rather than built. And Confluent is a founding member of the working group. The biggest vendor in the category is helping keep it open instead of fencing it.

What actually makes it a Streamhouse

A lakehouse is great at history and useless at now. A streaming platform is great at now and forgets nearly everything. Most enterprises run both and pay twice. Two pipelines. Two sets of business logic. Two numbers that disagree in the Monday meeting. Four things separate a Streamhouse from either one.

One table, two speeds. The same logical table reads as a live stream and as history. Not two copies you keep in sync. One asset, two read paths.

Incremental by default. Work is triggered by change, not by a clock. A late correction updates the affected result, not the whole partition.

Freshness as a dial. Seconds cost more than minutes. Minutes cost more than hours. You pick per table, instead of putting the whole estate on one setting.

One governance plane. Schema, lineage, access and retention defined once, enforced on the stream and the table alike. In regulated industries this is the feature that decides whether you can use any of it.

The architecture

The working group’s model is five stages. Capture, transport, transform, govern, serve. No product names, because these are capabilities and plenty of vendors sell each one.

Sub-second response works because nothing gets computed when the question is asked. Joins, aggregates and features are kept up to date as events land. The read is a lookup against state that is already right. A rough budget for a sub-second path: 5 to 20 ms to capture and commit to the log, 10 to 50 ms for stream compute and the state update, 1 to 10 ms for the serving lookup. Plenty of room inside 200 ms once you add network and application overhead. Govern sits in the middle of that sequence for a reason. The table formats and catalogs are not a downstream archive. They carry the schema, lineage, access and retention that the serving stage inherits. The table layer takes the same stream asynchronously, compacts the small files and holds the history. Analysts and model training read the same definitions the live path is serving, without sitting in its critical path.

Where this is genuinely mission-critical

One test. Does a late answer cost money or cause harm? If the report can wait until morning, you don’t need any of this.

Payments is the cleanest case. A fraud score needs the cardholder’s spend in the last sixty seconds, the merchant’s decline rate right now, and the device history going back a year. All in one decision. The first two are streaming state. The third is table history. A Streamhouse lets one model read both, without two teams maintaining two definitions of “velocity”.

Why this is happening now

Streaming isn’t new. It’s fifteen years old. So why does it become a named category in 2026?

Agents.

A dashboard tolerates stale data because a human reads it and applies judgement. An agent doesn’t. Give it last night’s stock figure and it will cheerfully promise inventory you already sold. That failure is silent, fast, and repeated at machine speed. So the advantage in enterprise AI is moving from the model to the context. Everyone rents much the same models. What differs is whether yours can see the business as it is right now, with the governance to prove where that came from. There’s a quieter benefit too. When the live path and the training path read the same governed tables, training-serving skew mostly goes away. That’s the thing that makes models look good in evaluation and behave badly in production.

None of this is free. Continuous processing costs more than a nightly batch. So ask the question your CFO would ask, table by table: what does a stale answer actually cost us? Where the answer is nothing, keep the batch job. Where the answer is a declined customer, a regulatory breach or an agent acting on fiction, the freshness pays for itself.

That’s the useful part of the working group. The pattern now has a name no vendor owns, which makes it much easier to argue on merit.

Sources

Fediverse reactions

Leave a comment