One has a bouncer on the door. One lets everybody in.

Two questions

Forget the words for a minute.

You will hear three names thrown around: warehouse, lake, lakehouse. People will tell you one is modern and one is old. That is not a useful way in.

There are really only two questions underneath, and the three names are just three different answers to them.

The whole of this case is those two questions. Everything else — the product names, the diagrams with arrows — falls out of them.

Case 01 covered why a warehouse is quick at adding up a column. This is a different thing: not how the data is read, but how it gets in and how it changes.

Question one

Is there somebody on the door?

A partner sends you data every night. Some nights it is perfect. Some nights a column is missing. Or an amount turns up as text. Or they have added a field and told nobody.

A warehouse has a bouncer. You tell it the shape in advance. Anything that does not match is usually turned away at the door.

More precisely: an analytical warehouse generally defines and checks a table’s shape when data is loaded. That is what people mean by schema on write. Treat that as a useful mental model, not a hard rule. Modern warehouses can hold semi-structured data such as JSON. Many also have loose staging areas where anything can land first.

A lake usually has no bouncer on that door. Files land in object storage without one central table shape being enforced as they arrive, and the structure is worked out when somebody reads them.

Say this one carefully, because it is widely misunderstood. It does not mean a lake has no schema, no checks and no rules. It means nothing is enforcing one table shape at the moment of landing. Plenty of lakes have strict validation in the loading jobs, a catalog describing every folder, and well-governed tables built on top. That is a choice each team makes, not something the storage decides for them.

The two names for this are schema on write and schema on read. Neither helps much on first hearing. Check at the door, or check when you read — that is all they are describing, and either can be made stricter than its name suggests.

What each one costs

Neither answer is free.

That is a real trade and reasonable people land on both sides of it. What is not reasonable is pretending one side has no cost, which is how most of these articles read.

What happens if nobody minds the lake

It becomes a swamp.

This is the word people use and it is the right one.

Two years of landing everything, and nobody wrote down what any of it was. There are four thousand folders now. Some are duplicates. Some were a one-off experiment in 2024. Nobody knows which ones anything depends on.

Worth saying plainly: a lake going bad is not a failure of the technology. It is what happens when “we will sort it out later” meets two years.

Question two

Why changing one row is awkward.

A lake is a pile of files sitting in cloud storage. That is genuinely all it is.

And the data files in it are usually Parquet. Those are not built for changing one row. A database can reach into a page on disk and edit a few bytes in place. A Parquet file in object storage is not designed to be poked at that way.

So changing one row normally means one of two things. Rewrite the file that row lives in. Or write a new file, and record somewhere that it replaces part of the old one.

So think about what that means for something completely ordinary. A customer moves house. One row, one field, in a table of eight million rows.

The next page lets you do it and watch roughly what each one has to shift to make it happen.

The actual invention

A lakehouse is a list of which files count.

That is it. That is the whole invention, and it is far less magical than the word suggests.

A plain lake says: this table is whatever files are in this folder. A lakehouse keeps a small list beside it, saying which files make up the table right now. The folder can hold other things too. Only what is on the list counts.

That is the intuition, and it is worth holding on to. Now the fuller version. What sits beside the files is a metadata and transaction layer. The thing that provides it is called a table format, and there are three you will meet: Delta Lake, Apache Iceberg and Apache Hudi.

The files on their own are just files. The metadata tells a query engine which physical files make up the table right now. That is the difference between a folder and a table.

Each of the three table formats does this its own way, and none of them is literally one plain text list. “A list of which files count” is the right picture to carry; just do not expect to open one and find it.

That last point is what people mean when they say a lakehouse gives you transactions on a pile of files. Nobody ever sees a half-finished change, because the switch is one small write at the end.

It also means yesterday’s version is still described, so you can read yesterday’s table back exactly. That is a useful thing to have the morning after a bad load.

Why the metadata matters

Nobody ever sees a half-finished table.

Once there is a record of which files count, four useful promises become possible. People bundle them under one word, ACID, which is an acronym and not an explanation. Here they are using the change you just made.

And it is one small write that does all of this. The new data file can take as long as it likes; nothing changes for anybody until the metadata moves from one version to the next.

Notice what is not in that picture: file C being deleted. Old files and old versions usually stay for a while. That is how you read the table as it was last Tuesday, or undo this morning’s bad load. They get cleaned up later, on whatever schedule you set.

Reading an earlier version has a name: time travel. It is a side effect of keeping the history, not a separate feature somebody had to build.

The harder version

Now try deleting a person.

Changing one row was awkward. Removing somebody entirely is the same problem with the volume turned up, and you have met it already — in Case 06, Asha asked to be deleted.

Her rows are not in one convenient place. She has been ordering for three years, so she is scattered across hundreds of files.

find every file with her in it
read each one
write it out without her
swap the new file in
repeat, a few hundred times

delete from audit_events
where customer_id = 'C-77'

That is not a small convenience. Delete and update became real operations on data sitting in object storage, instead of a hand-written job somebody has to babysit. It is one of the main reasons table formats took over from raw lakes — and the reason has as much to do with the law as with engineering. A legal request to remove somebody is not something you want to answer with a script and a hope.

What the files are

Why everyone stores Parquet.

One thing has been sitting in the background of this whole case: the files themselves are usually Parquet, not CSV. That is worth two minutes.

A-1,Mumbai,120
A-2,Pune,80
A-3,Delhi,150

A-1 | A-2 | A-3
Mumbai | Pune | Delhi
120 | 80 | 150

So a lakehouse table is really three things stacked up, and none of them is new on its own:

How it got here

A lakehouse is not just a tidier folder.

Read in order, the whole thing is one question being answered step by step.

Every step there is answering a problem the step above it had. That is why the word exists, and it is a better thing to remember than any product name.

What it looks like in practice

The same folders, read two ways.

Say your company lands operational data every day. In storage it looks like this either way:

As a plain lake, those are folders with files in them. Anything reading it has to be told where to look and what it will find.

As a lakehouse table, the same files plus a metadata layer become one thing called audit_events, which you can query by name.

select * from audit_events
where day = '2026-09-30'

metadata → these files are current
folders  → only day=2026-09-30
stats    → and only these parts

Skipping whole folders because of how they are named is called partition pruning. Skipping files because of the notes kept about them is the block-skipping from Case 01. Same trick, one level up.

The old arrangement

Why people ended up running both.

For years the normal setup was one of each. Raw files land in the lake. A job cleans them and loads the result into the warehouse. Analysts use the warehouse. Data scientists use the lake.

It works. It also quietly charges you for things nobody puts in a budget.

A lakehouse is an attempt to have one copy instead of two. That is the pitch, and it is a reasonable one. Whether it is worth changing a working setup for is a different question, and usually the answer is no.

Choosing

Which one, and honestly.

There is no winner here. There is a fit between what you have and what you need, so the useful thing is a list of conditions rather than a verdict.

Those five things decide it. Not which architecture is newer, and not which one reads better in a design document.

Three things people say

And why two of them are wrong.

If you get asked

“Would you use a lake or a warehouse here?”

Do not answer with a preference. Answer with questions, then a choice, then what it costs you.

Ask what the data looks like. Mostly tables, or a mix of logs and files and things nobody has classified? That alone decides most of it.

Ask who reads it. Analysts writing SQL against known tables want a warehouse. People experimenting with raw events want the raw events.

Then say when the checking happens. That you would check the shape at the door if the data is well understood, and later if you need to keep everything. That one sentence is the whole topic and almost nobody says it.

Then mention changing a row. Parquet files are not built for editing one row in place. An update usually means rewriting that file, or writing a replacement and updating the table’s metadata. That is why formats which keep a list of current files exist at all. This is the part that sounds like experience.

Finish with the trade, out loud. There is no answer here that costs nothing, and saying so is the answer they are listening for.

Two questions

Did it land?