Streamhouse: What It Is, What It Isn't, and What's Missing

Last week, a group of streaming vendors published an open definition of "Streamhouse" and formed a working group around it. Today Apache Fluss, the streaming-storage layer Ververica now puts under its own Streamhouse, shipped 1.0. Busy week for a word.

The timing is interesting:

• Databricks and Snowflake are adding Kafka-protocol ingest endpoints (Zerobus in beta, Datastream in private preview).
• The analytical/operational boundary is blurring. Agents don't care which side they read from.
• So the operational vendors need a path to market of their own, and to claim it. I agree with that.

Conduktor is not (yet?) in the working group, so I read the Streamhouse definition as anyone working in the space would: interested and skeptical at the same time. Naming an existing pattern and marketing it hard is not new: Data Mesh, Lakehouse, Medallion.

As defined today, Streamhouse is generic. From where I sit, it's a classic data fabric with a serving layer:

What it is

The definition, verbatim from streamhouse.com:

"Streamhouse architectures empower organizations to capture, transport, transform, govern, and serve the current state of their business continuously, so that production applications and agents can act on it."

It insists on real-time (you run your business continuously, so does your operational data), production-native (obviously), and decentralized (data lives in multiple systems and that's fine, no need to consolidate).

A typical implementation:

CDC (Debezium) → event streams (Kafka) → stream processing (Kafka Streams or Flink)
  → open table format (Iceberg) → data catalog → low-latency serving (HTTP API or SQL)

Streamhouse is a data architecture, not a vendor or an open-source project. Kafka is the dominant transport today, but per the definition it could be anything else.

I can't help thinking about Lakehouse here. Let's take a detour.

Lakehouse: what it is, what it isn't

Lakehouse was pushed hard by Databricks: they coined it in 2020 and defined it in 2021 in their CIDR paper, Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics:

"a data management system based on low-cost and directly-accessible storage that also provides traditional analytical DBMS management and performance features such as ACID transactions, data versioning, auditing, indexing, caching, and query optimization."

It's specific. It names the technical building blocks (transactions, tables on object storage, etc.) and the guarantees, so you know what it takes to have a Lakehouse and what you get from it.

A quick comparison with Streamhouse as of today (hopefully this evolves quickly):

	Lakehouse	Streamhouse (Sept 2026)
Name coined by vendor(s)	yes	yes
Commercial interest	obvious	yes?
Problem being solved	two copies, lake and warehouse	business state is stale by the time it's usable
Primitive	table on object storage	?
Storage model	defined	?
Expected guarantees	ACID, versioning, schema, time travel	?
"What is not one?"	clear	unclear

What Streamhouse is missing are primitives and guarantees. This will come. Without them, you don't know whether you have a Streamhouse or not. You don't know what you need. And without that, you don't know why you need it.

Streamhouse was already being defined

Ververica introduced the word at Flink Forward in October 2023, on Flink, Flink CDC and Paimon. Its current Streamhouse page describes a specific architecture: Flink for compute, Fluss for streaming storage, an open table format for history, Flink SQL on top. Its pitch is consolidation: "One architecture for streams and tables, real-time and historical, ingestion and analytics. One SQL engine. One governed source of truth." The enemy is duplication: "Two pipelines. Two storage layers. Two query engines. Two governance models."

Fluss says the same thing about its primitive: "Kafka is the streaming transport. Fluss is the streaming storage." Tables, not topics.

	Streamhouse, original	Streamhouse, working group
Idea	streaming lakehouse	continuous business-data architecture
Primitive	the table (stream/table duality)	?
Stack	Flink + Paimon (2023), then Flink + Fluss + open tables	vendor-neutral
Goal	collapse systems and copies	"meet data where it already lives"
Governance	one control plane, one source of truth	?
Architecture	concrete	?

The new definition is close to the opposite of the original instinct. The original centralized so it could govern once, whereas the new one is all about crossing systems and decentralization.

Don't get me wrong: both concepts have merit and serve different purposes, but it's quite confusing for now. Hopefully this gets clarified quickly.

The trademark is held by Alibaba Cloud and licensed to Ververica, which administers it for the working group. Note that "Lakehouse" and "Data Mesh" spread with no trademark at all.

What isn't a Streamhouse?

Tell three architects "build me a lakehouse without Databricks" and they will converge on a similar solution: object storage (S3), Parquet files, a transactional table format, a catalog, a query engine on top. They'll argue Iceberg versus Delta, and that's it.

Now tell them "build me a Streamhouse" and you may get:

Architecture	Real-time	Decentralized	Streamhouse?
Postgres → Debezium → Kafka → Flink → Iceberg	yes	yes	yes?
Postgres → Kafka → microservices, no lake at all	yes	yes	yes?
Snowflake → Kafka → application	yes	yes	yes?
Pulsar → custom processor → Cassandra	yes	yes	yes?

Tell me what in the definition makes any of these wrong. The outcome is served ("business state is continuously available"), but what about the architecture?

Is this "Kafka to Iceberg" with a new name? Probably not. Time will tell.

Decentralized makes governance harder

I'm all for decentralization. Use specialized systems for specialized tasks. It also means the same business fact (customer address, account balance, order status) now lives in, and moves through, several systems:

Postgres → CDC → Kafka → Flink → Iceberg → warehouse → application / agent

In each of these systems, the data has its own custodian, its own access model, its own SLA, its own schema:

• Postgres: grants, the DBA team.
• Kafka: ACLs and quotas, the platform team.
• Flink: job ownership, whoever deployed it.
• Iceberg: catalog permissions, the data team.
• Warehouse: roles and masking policies, analytics.
• The application or agent: whatever it was handed.

Governance is about answering non-technical questions:

• If the source is reclassified as personal data, how many systems have to change, and who finds out?
• Who owns this sensitive data once it's in the topic, and who makes sure regulations are respected?
• When an agent reads data that turns out to be stale, how do we find where the delay came from?

In a centralized design, it's easier to get one answer because there's one system. In a decentralized design, you may have many people involved and nobody answering for the whole path. The more decentralized a Streamhouse gets, the less its governance can belong to any one component.

Governance isn't a box in the pipeline

Let's talk about this chain: capture → transport → transform → govern → serve.

I find it outrageous that "govern" is just a box late in the diagram, as if governance were a simple checkbox step. Governance is not "we have a data catalog, happy days". Putting it there shows either a narrow view of the end-to-end data lifecycle or a massive tech bias.

• Ownership exists before capture.
• Classification has to survive transformation.
• Access is decided at every write and read.

Governance is a foundation running across the whole pipeline:

• data identity
• ownership
• classification
• contracts and schemas
• lineage
• permissions
• SLAs and freshness
• operational state (is the path healthy right now?)

A data catalog is part of it. It's where much of this should be written down, but a typical catalog only describes data at rest (ready to be served via HTTP or SQL). It doesn't see the record in flight between Kafka and Flink, it doesn't enforce on the wire what it declares, and it has no idea whether the pipeline still matches what the metadata says. I would argue that a decentralized data architecture needs a logically unified control plane, even if its data plane stays decentralized.

Each system keeps its own engine, storage and access model. What's unified is the view: one place where the identity, ownership, policy and state of a business asset stay coherent from source to consumers, end-to-end.

Why now?

The working group's stated reason: "Organizations are beginning to deploy applications and AI agents that do more than analyze what happened in the past: they make decisions and take action as business events unfold."

I couldn't agree more, but this is not new. AI agents amplify the need for easy access to up-to-date data with governance built in. Since agents interpret data and can show emergent behavior, narrowing down what they can do and access matters even more.

There is a trend of calling a model on every event. No.

• High-throughput streams stay the domain of stream processors, rules and deterministic ML.
• Agents show up at the edges, on low-volume flows, where something needs context, judgment or orchestration.

events (high volume)
   ↓  stream processing / rules / ML
interesting state, anomaly, needs a decision (low volume)
   ↓
AI agent

not:

event → LLM
event → LLM
event → LLM

What I'd like to see next

It's a good first shot, but the community needs more. How do we turn this concept into a useful architecture?

1. What is not a Streamhouse?
2. What are the guarantees?
3. How do data identity, ownership, and policies travel across systems?
4. What does "govern" mean in a decentralized architecture?