**The Riverhouse — **A New Word for an Old Trade-Off

The data platform industry has been converging on something it doesn’t yet have a name for.

For a decade, the field has operated on an unstated assumption: that scale, structure, and speed are three things you choose between. You build a Data Lake for scale and accept that querying it reliably is hard. You build a Data Warehouse for structure and accept the rigidity and vendor lock-in that come with it. You build an Operational Data Store for real-time responsiveness and accept that it sits in isolation from your analytical layer.

The emerging Lakehouse ecosystem — Apache Iceberg, Project Nessie, Apache Polaris, and Dremio — has quietly dismantled this assumption. The trade-off is no longer technically necessary. But the industry hasn’t named the destination it’s building toward.

That name is the Riverhouse.

Why naming matters

Architecture patterns that lack names are architecture patterns that get rebuilt from scratch in every organization that needs them. The Data Lakehouse gave a generation of data engineers a shared vocabulary for the convergence of the lake and warehouse. But the Lakehouse stopped short: it merged two of the three layers and left the Operational Data Store as an afterthought — a separate system connected by brittle pipelines or simply absent from the architecture altogether.

The Riverhouse completes the convergence. It is a unified data ecosystem that brings the scalability of a Data Lake, the governance of a Data Warehouse, and the real-time responsiveness of an Operational Data Store into a single coherent architecture — not through complex ETL pipelines stitching three separate systems together, but through open standards that make the distinction between layers a logical one rather than a physical one.

The result is a platform where engineers spend their time on business logic rather than data movement.

The three layers, unified

The Lake dimension

The Lake dimension provides the foundation: low-cost object storage, schema-on-read flexibility, and the ability to ingest raw data at any speed without upfront transformation. Apache Iceberg’s table format sits atop this storage layer, adding ACID transactions, snapshot isolation, and partition evolution — the reliability properties that historically required a warehouse — without sacrificing the openness of cloud object storage.

The Warehouse dimension

The Warehouse dimension provides structure and queryability: a semantic layer that translates raw storage into governed, business-ready datasets. In the Riverhouse, this is delivered through virtual datasets and semantic views rather than physical materialization — a change in upstream schema propagates through the semantic layer without rewriting tables or rerunning pipelines. The structure is real; the rigidity is not.

The Operational dimension — and the role of PostgreSQL

The Operational dimension is the piece that the Lakehouse left out. It provides real-time responsiveness, and for most organizations, it already has a name: PostgreSQL.

Postgres is the de facto operational backbone of the modern enterprise. It powers transactional applications, serves as the system of record for product data, and underpins operational reporting across industries. In legacy architectures, it sat in isolation — a source system that fed the analytical layer through near-real-time and batch jobs, with the latency and data quality degradation that implies. In the Riverhouse, that isolation ends.

Rather than treating Postgres as an upstream silo, the Riverhouse connects it directly through logical replication. PostgreSQL’s Write-Ahead Log — via pgoutput or wal2json — becomes a continuous stream of row-level change events: inserts, updates, and deletes captured in real time and written to Apache Iceberg tables via CDC pipelines. The moment a transaction commits in Postgres, its downstream effect propagates into the unified architecture without a batch window, without a pipeline redeploy, and without duplicating the data into a separate store.

This is the ODS integration the Lakehouse never addressed. Postgres doesn’t disappear from the architecture — it remains the operational system of record it has always been. What changes is its relationship to the analytical layer: from a disconnected source to a live participant.

What makes this possible now

Four developments in the open data ecosystem have made the Riverhouse architecturally achievable.

PostgreSQL logical replication

PostgreSQL’s logical replication has matured to the point where row-level change capture is a first-class operational concern rather than a specialist integration task. Tools like Debezium consume the Postgres WAL and emit structured change events that downstream Iceberg writers can consume directly. Schema changes in Postgres propagate through the CDC pipeline without manual intervention.

Apache Iceberg v3

Apache Iceberg v3 brings deletion vectors, row-level lineage, and instant schema evolution to the table format layer. This is what makes Postgres CDC viable at scale: Iceberg can accept row-level updates and deletes — not just append-only inserts — meaning the Iceberg table reflects the current state of the Postgres source without full reloads or merge complexity. Schema changes no longer require backfill jobs. Partition layouts adapt to query patterns without rewriting existing data.

Git-for-Data catalogs

Project Nessie and Apache Polaris bring branching, tagging, and multi-table atomic commits to the catalog layer. Data changes can be isolated, tested, and promoted across environments with the same discipline that code changes receive in a CI/CD pipeline.

Autonomous query acceleration

Dremio’s Reflections mean that performance optimization no longer requires human intervention. The platform observes query patterns and builds acceleration structures in the background. A user queries their data; the platform intercepts the query and serves it from a precomputed structure. The performance is real; the operational overhead is not.

Together, these components form a stack where the platform manages its own complexity. PostgreSQL contributes to the operational system of record. Iceberg contributes the unified storage layer. Nessie and Polaris contribute to catalog discipline. Dremio contributes the query and semantic layer. No single vendor controls all four. The Riverhouse is not a product you buy. It is an architectural philosophy you build toward — and the components to build it are available today, in open source, without lock-in.

The lexical gap this fills

The industry already uses “Data Lakehouse” to describe the convergence of lake and warehouse. The Riverhouse is not a replacement for that term — it is an extension of it.

A Lakehouse that incorporates real-time operational data — sourced live from systems like PostgreSQL via CDC — a semantic layer capable of virtual delivery, and autonomous operational management is a Riverhouse. The distinction is meaningful because it changes what the architecture promises: not just unified storage and compute, but unified time — the same platform serving historical analytics, governed reporting, and operational workloads without the latency, duplication, and operational burden of separate systems.

For most organizations, the Riverhouse already has a starting point: a Postgres database that knows everything about today, and a data lake that knows everything about the past. The Riverhouse is the architecture that makes those two things one and the same.

Data platform leaders who are already building toward this destination now have a word for it.

Built on: PostgreSQL · Apache Iceberg · Project Nessie · Apache Polaris · Dremio

**Image: **Generated using Gemini