If your team can’t show you an integrated silver layer, you don’t have a lakehouse. You have a dump house: your operational systems copied into cloud storage with better file formats and three folders named after medals.

That sounds harsh until you check what the middle layer is supposed to hold. The Databricks medallion glossary asks for silver data that is matched, merged, conformed and cleansed. Every one of those verbs assumes somebody agreed what the data means. Matched on which keys? Merged how, when two sources disagree? Conformed to whose definition, and recorded where? If nobody made those decisions and wrote them down, nothing in the middle is integrated, however tidy the folders look.

Bronze always ships, so everyone mistakes it for progress

Count the people it takes to land a source table in the bronze layer. You need a data engineer, whoever owns the source system, and a platform engineer. All three sit inside technology, and all three are bookable this week. Bronze asks nothing else of you. The source system already made every structural decision, and your database is not your business. So every tool ships source-to-bronze first, and the early weeks feel good. Row counts match and the dashboard glows.

Now count the people silver needs. The engineer is still there, joined by the modeler and the steward. Add the business expert who can say billing’s account and support’s login are the same customer, and the architect who holds that line when two departments count differently. Silver is the only layer where all of them are core at the same time, and they’re exactly the people with the least available time.

So silver slips a sprint, then a quarter. Then it quietly shrinks into a rename pass over bronze with a patchwork of views on top. That’s the dump house. On the slide it still looks like a medallion architecture. Underneath, the decisions nobody scheduled got made anyway, at the keyboard, unrecorded.

How do you know whether you built a lakehouse or a dump house?

Open your silver layer and ask one question that spans two business units. How many customers do you have, and which of them buy from both product lines? A data lakehouse can answer it, because silver records which systems know a customer and how each of them maps to the one Customer the business means. A dump house has no answer. The answer never lived in any system you copied. Each source table has a friendlier name now. Nothing else about it changed.

Then comes the second half of the test. Somewhere it has to be written which system wins when two sources disagree. If that somewhere is “in a meeting” or “in the pipeline code”, the ruling lives in one engineer’s head, and the next pipeline will guess again. Data integration leaves a record, and that record is a mapping that names the business entity, the source columns feeding it, and the precedence rule.

No record means no integration, whatever the layer is called.

Which shape you pick matters less than picking one in writing

None of this is an argument for a modeling religion. Data Vault, third normal form, a dimensional-first middle and one big table can each carry an integrated silver layer. Not one of them does the integrating for you. The shape is a decision you make once and write down, on the things that differ between companies. Here are four of them.

  • Change frequency: how often the sources change.
  • Audit demands: how much history the business needs to keep.
  • On-call skills: who will maintain the layer once it’s live.
  • Query cost: what it costs to read the result.

What you can’t do is skip the decision and call the result an architecture. The book’s chapter on choosing a shape gives each shape an honest paragraph, then hands you a longer list of factors to decide with.

A team that skipped silver has not modeled anything

A team that lands two hundred tables and builds gold straight off them, a view per report, has done ingestion and reporting, and nothing more. Data modeling starts somewhere else entirely. It starts where two systems disagree about what a customer is, and somebody has to rule, record the ruling, and build the structure that conforms to it.

A team that’s never done that has never modeled your business, whatever its job titles say.

Make the time, starting with one subject area

Nobody has time, and that’s the diagnosis rather than the excuse. The steward is half of somebody’s job, and the business expert gives you an hour every two weeks. So those hours have to go on the decisions only those people can make, not on plumbing. If you lead a data team, you don’t need to learn to code. You need to understand the silver layer well enough to ask for it, and to recognize a dump house when one is presented to you as an architecture.

The Data Lakehouse for Everyone is a free ebook we wrote for exactly that reader, whichever chair you sit in, on any stack. Two chapters get you moving, and the six steps in a single post are the short read.

  1. Pick one subject area, and spend the scarce hours on its rulings. Start with which records are the same customer and which system wins when two sources disagree.
  2. Read why the silver layer fails for the mechanism behind every stalled program.
  3. Run the book’s six steps on that subject area, and watch the second subject go faster than the first.