What an Open Data Lakehouse Is, and Why You No Longer Have to Choose Between Trustworthy and Affordable
The term “data lakehouse” has entered circulation quickly enough to invite suspicion that it is more branding than substance. It is not. It denotes a specific architectural pattern (open storage combined with a transactional table layer) that resolves a trade-off organisations have worked around for the better part of three decades. It is also the foundation on which the rest of our platform is built, so this first article in the series establishes that foundation before the later parts examine each layer of the stack in turn.
The aim here is a precise but accessible account: what a lakehouse is, in concrete terms, and why it supersedes the two architectures that preceded it, the data warehouse and the data lake. If your organisation has ever had to choose between data it could trust and data it could afford to keep, this article explains the origin of that constraint and why it no longer applies.
The choice you used to be forced into
To see why the lakehouse matters, you have to see the trade-off it removes, because for thirty years, you had to pick a side.
If you wanted serious analytics, you built a data warehouse. Data went in structured and governed, the numbers were reliable, and queries were fast. Finance teams have run on warehouses for decades for exactly that reason: you can trust the output. The price of that trust was cost and rigidity. A warehouse ties storage and computing power together, so keeping years of detailed history online is expensive enough that most organisations quietly don’t, and throw older detail into cold archives instead. And because you have to define the structure before the data arrives, every new kind of data is a project. Warehouses are trustworthy and inflexible, and you pay for every gigabyte you keep.
Then cheap storage arrived, and with it the data lake, the warehouse’s opposite. Throw everything into inexpensive storage, decide what it means later, keep as much as you like. The cost problem vanished. A new one took its place: without structure or guarantees, a lake fills up with files nobody can vouch for. The number you got yesterday and the number you get today don’t match, and you can’t say why. The industry nicknamed the result a “data swamp,” which is unkind and also fair.
So the choice was genuinely bad. The warehouse was reliable, costly, and rigid. The lake was cheap, flexible, and untrustworthy. Many organisations ended up running both (a lake for raw data, a warehouse for the governed numbers) and paying, forever, to copy data between them. That two-system setup is still everywhere. It’s also where a great deal of cost and complexity quietly goes.
What the lakehouse does
A lakehouse is the refusal to keep making that trade. It takes the cheap storage of the lake and adds back the reliability of the warehouse, so you don’t need both.
Here’s the idea without the machinery. Your data sits in cheap, open storage, the way it would in a lake. On top of it sits a layer that provides the things the warehouse used to provide and the lake couldn’t: consistency, so a half-finished write can’t corrupt your data; the ability to change structure without rebuilding everything; the ability to look at your data as it stood at a point in the past; and the ability for different tools to read the same data at once without tripping over each other. A query engine reads the data where it sits. Nothing gets copied into a separate, proprietary system first.
Why it beats the warehouse/lake trade-off
Put the three side by side and the point is obvious. The warehouse gave you reliability but made you pay for it in cost and rigidity. The lake gave you cheap flexibility but took away the reliability. The lakehouse is the first option that gives you both at once (reliable like a warehouse, cheap and flexible like a lake) which is why it’s replacing the old habit of running the two together and copying data between them forever.
Why that matters, in three consequences
Architecture is a means to an end, and the end is three practical things.
History becomes affordable to keep queryable. The difference between “we have five years of data somewhere” and “we can query five years of data this afternoon without raising a request” is the difference between an archive and an asset. Because the storage is cheap, you can afford to keep the detail reachable instead of boxed away.
Your data stays described in an open format, which means you’re not dependent on one vendor to read it. This sounds abstract until a contract renewal, and then it’s the only thing that matters. It’s also the reason this is specifically an open lakehouse rather than a proprietary one, and it matters enough that the next article in this series is devoted to it.
And storage and computing power scale separately. A big query that needs a lot of horsepower for an hour doesn’t force you to run a permanently larger, permanently more expensive system the other twenty-three hours of the day. You pay for the work when you do the work.
What it isn’t
A quick word on what a lakehouse doesn’t do, because the honest version of this is more useful than the sales version.
It isn’t magic that fixes bad data. If what goes in is incomplete or wrong, a lakehouse will faithfully store a complete, confident version of a wrong picture. Getting the data right comes first; the architecture doesn’t do it for you.
It isn’t only for technology companies. In fact the organisations that get the most from it are often the ones that weren't originally marketed to utilities, retailers, telecom operators, banks, public bodies anywhere. The data is genuinely large, spread across systems that don’t talk, and subject to real rules about where it can live. We’ll get to who it fits and why across this series.
And it isn’t a single product you buy and switch on. It’s an architecture, assembled from a set of open components, each doing one layer of the job. That’s the real subject of this series: not the word “lakehouse,” but the specific technologies that make one work.
The stack we’ll walk through
So here is the ground we’ll cover.
The open table format : Apache Iceberg, Hudi and Delta Lake, the layer that keeps your data open and portable, which is where we go next.
Storage and compute: MinIO, Dell and others, where the data physically lives, and why that’s often the whole decision.
Ingestion and processing: Kafka, NiFi, Spark, how data gets in, in real time and in bulk.
The query engine: Trino and Starburst, how you ask questions of data without first moving it.
And consumption: Superset, Power BI, Grafana, how it finally becomes something a person can see and act on.
Each of these gets its own article. By the end, “lakehouse” won’t be a concept you take on trust; it’ll be a stack you can picture, component by component.