A data lakehouse is an architecture: object storage, an open table format such as Apache Iceberg, a catalog, and multiple engines reading the same tables. Medallion architecture is a layering convention: bronze for raw data, silver for cleaned data, gold for business-facing aggregates. They are not alternatives. You run medallion inside a lakehouse, and the question worth arguing about is not which to pick but how many of those layers need to be physical copies.
Search for either term and you will find comparison posts putting them side by side with a feature table, as though a team were choosing between them. That framing is wrong, and it matters because it hides the decision that actually costs money.
One term describes what your platform is made of. The other describes how you name and promote tables inside it. You can run medallion on a lakehouse, on a cloud warehouse, or on a pile of Hive tables from 2015. You can run a lakehouse with medallion, with a star schema, with data vault, or with no convention at all and a directory called final_v2.
The real question is how many physical copies of your data each layer justifies, and the honest answer for most organisations is fewer than they have.
A useful test for whether two things are alternatives is whether choosing one prevents the other. Choosing Iceberg over Delta prevents you from using Delta. Choosing a lakehouse over a medallion architecture prevents nothing, because they occupy different slots.
The lakehouse slot is filled by decisions about storage, format, catalog and engines. The medallion slot is filled by decisions about naming, layering and promotion. A platform has to answer both, and answering one tells you almost nothing about the other.
This is worth being pedantic about because the category error produces bad advice. A post arguing you should adopt a lakehouse instead of medallion is arguing that you should replace your storage layer instead of renaming your tables.
Four components, and the interesting property is which ones are separable.
Data files live in S3, ADLS, GCS or an S3-compatible store. Storage is decoupled from compute, which is what makes it possible for several engines to read the same bytes without one of them owning the data.
Apache Iceberg, or an equivalent. The format is what turns a directory of Parquet files into a table with atomic commits, schema evolution, time travel and predicate pushdown driven by real statistics rather than directory names.
Something that answers which files make up this table right now, and who is allowed to touch it. Apache Polaris, or another Iceberg REST Catalog implementation. Without it you have table files without table identity, and every engine has to be told where things live.
Spark, Flink, Trino, StarRocks, Dremio, DuckDB, a Python script. None of them owns the data. That is the property that distinguishes a lakehouse from a warehouse that happens to keep files in object storage.
Notice what is absent from that list. Nothing about bronze, silver or gold, nothing about how many transformation stages you run, and nothing about naming. The architecture is silent on layout, deliberately.
Three named tiers, each with a promise about what the data in it guarantees.
Raw data as it arrived, appended and not modified. Its purpose is replay and audit. If a transformation turns out to be wrong, bronze is what you rebuild from, and its value comes entirely from being untouched.
Bronze should not be a query target for analysis. Teams that let dashboards read bronze have converted their audit copy into a production dependency, which means they can no longer change it.
Typed, deduplicated, conformed. Bad records handled, keys resolved, schemas aligned across sources. This is the layer that carries the most weight, and in a well-run platform most questions are answerable from it directly.
Aggregated and shaped for a specific consumer: a dashboard, a model, a finance report. Gold is a cache with a business name, and treating it as one is clarifying. Caches need a reason to exist, an invalidation story, and a way to tell when they are stale.
Read those three definitions again and notice what is missing. None of them requires a physical copy. They describe guarantees about data, and a guarantee can be delivered by a view as easily as by a table.
Medallion is a Databricks convention, popularised around Delta Lake, and it made complete sense in the environment that produced it.
That environment had specific properties. Transformation meant a Spark job. Serving queries directly over a raw layer was slow enough that materialising each stage was clearly worth the storage. Views over large datasets were not a realistic serving mechanism. And a pipeline was a chain of batch jobs, each reading one table and writing another.
Under those constraints, materialising every layer is not just reasonable, it is the obvious design. The convention encoded the reality of the tools.
Several of those constraints have weakened. Query engines got substantially better at reading raw and semi-processed data quickly. Iceberg brought real statistics and partition pruning, so a filtered scan over a large table stopped being a full read. Engines gained view support and materialisation strategies that let a logical layer perform like a physical one when it needs to.
The convention outlived the constraints that produced it, which is the usual way a sensible practice turns into a ritual. That is not an argument against medallion. It is an argument for re-deriving it rather than inheriting it.
Here is the decision that the lakehouse-versus-medallion framing hides.
If bronze, silver and gold are each physical tables, you are storing the same facts three times, running three sets of jobs, maintaining three sets of Iceberg tables, and accepting that gold is as fresh as the slowest job in the chain.
Sometimes that is exactly right. A gold table feeding a dashboard that runs a thousand times an hour, built from an aggregation over a billion rows, should absolutely be materialised. Computing it per query would be indefensible.
Often it is not right. A gold table that joins two silver tables and filters to one region, queried a few times a day by one team, is a copy that exists because the convention said there should be three layers.
The convention gives you a vocabulary for guarantees. It does not tell you which layers deserve to be physical, and that question has to be answered per table with the platform you actually have.
Four questions, and materialise when you can answer yes to enough of them.
Is the transformation expensive and reused often? Expensive computation repeated many times is the textbook case for a cache. Cheap computation, or expensive computation run twice a week, is not.
Does it need its own retention or permissions? A physical table can be governed and retained independently. If gold must survive after silver is purged, or must be readable by people who cannot see the underlying detail, that is a real reason to materialise. Though it is worth checking whether your catalog can express the permission difference over a view first, because many can.
Do consumers need a stable contract? A published table that many teams build against benefits from being a deliberate artefact with a schema you change carefully. That is an organisational reason rather than a technical one, and it is a legitimate one.
Is the engine genuinely too slow over the layer below? Measure this rather than assuming it. A lot of materialisation exists because someone benchmarked a query in 2019 on a different engine against a Hive table.
Four noes and you have talked yourself into a copy that will drift from its source and that someone will have to reconcile during an incident. Views cannot drift, which is a property worth more than it usually gets credit for.
Storage is the cost everyone names and the least important one.
Freshness is the first real cost. Gold is only as current as the last run of the job that built it, and each layer adds its own lag. A three stage chain of hourly jobs means a number on a dashboard can be three hours old while every input was current.
Correctness is the expensive one. Fix a bug in silver and gold stays wrong until it is rebuilt. Now you have two versions of the same number in circulation, and someone in a meeting is quoting the stale one. Every copy is a place where the truth can be out of date.
Maintenance triples with the copies. Each physical Iceberg table needs compaction, snapshot expiry and occasional orphan cleanup. Three layers of tables is three times the maintenance surface, and the layers you materialised out of habit are maintained with the same diligence as the ones you needed.
Lineage gets harder in a way that shows up when a number looks wrong. Three hops means three places to check and three jobs whose run history has to be correlated before anyone can say where the discrepancy entered.
Someone needs a field that silver drops, so they query bronze directly. It works, so it spreads. Now the raw layer has consumers, which means changing it breaks things, which means it is no longer the replay copy it was supposed to be.
Bronze, silver, gold, then a staging layer between bronze and silver, then a platinum layer above gold, then a semantic layer above that. Each addition is locally justified and the aggregate is a pipeline nobody can reason about.
The number of layers should be derived from the number of genuinely distinct guarantees you need, and that is rarely more than three.
The most common form of waste. A gold table that selects from one silver table with a filter and two renamed columns is a view someone materialised out of convention.
The layer is called silver, the promise is deduplicated and conformed, and in practice it is bronze with the column names cleaned up. The names then actively mislead, because everyone downstream trusts a guarantee nobody implemented.
A reference table of forty country codes updated twice a year does not need three layers. It needs one table. Conventions applied without judgement produce ceremony.
Medallion is not the only option, and it is worth knowing what it competes with.
Facts and dimensions in a star schema. Older, extremely well understood, and still the best answer when the primary consumer is BI tooling. It organises by meaning rather than by processing stage, which is a different and often more useful axis.
Hubs, links and satellites, optimised for auditability and for absorbing source changes without remodelling. Heavy, and genuinely appropriate in regulated environments where lineage is a requirement rather than a nice-to-have.
Organise by business domain first and processing stage second, so ownership follows the org chart. Popular with data mesh thinking. It composes with medallion rather than replacing it: each domain can run its own three layers.
Keep raw and conformed physical, and express everything above them as governed logical definitions that the engine can accelerate when it needs to. This is the direction that gets more attractive as engines get better at views and materialisation, and it is the one that shrinks the copy count most.
Start with the lakehouse decisions, because they are the ones with real switching costs. Storage, table format, catalog, engines. Get those right and they will outlive several generations of layout convention.
Then adopt medallion as vocabulary rather than as law. Bronze, silver and gold are useful words because everyone knows roughly what they mean, and a shared vocabulary for guarantees is worth having.
Then decide materialisation per table, with a reason you could defend in a review. Some gold tables earn their existence and should be materialised, partitioned and compacted deliberately. Others are views that were never questioned.
If you want one concrete exercise, take your gold layer and count how many of its tables could be views today without anyone noticing. In most platforms the answer is more than half, and each one you convert is a copy you stop maintaining and a place truth can no longer go stale.
Dremio is a query engine and semantic layer over an open lakehouse, which puts it directly in the middle of this argument. It queries Iceberg tables in place, and it lets you define logical layers as views that the engine can accelerate rather than as pipelines that copy data forward.
The practical effect is that the copy question gets easier to answer honestly. When a logical gold layer performs well enough for its consumers, the case for materialising it has to be made on its merits rather than on the engine being too slow to consider the alternative.
Dremio also co-created Apache Polaris and donated it to the Apache Software Foundation, which matters here for a boring reason: whatever layout convention you land on, the catalog is what makes those layers visible to every engine rather than to one.
Not lakehouse or medallion. Both, and then a harder question: which of these layers has earned the right to be a physical copy.
Every copy you keep costs freshness, correctness and maintenance, paid continuously and mostly during incidents. Every copy you eliminate removes a place where two versions of the same number can disagree. That is the trade to argue about in your next design review, and it is a much more productive argument than the one the comparison posts are having.
No, and they are not alternatives either. A lakehouse is an architecture made of object storage, an open table format, a catalog and multiple engines. Medallion is a convention for organising tables into bronze, silver and gold layers. Medallion runs inside a lakehouse, or inside a warehouse, or inside anything else that holds tables.
You need the guarantees the layers describe: something raw enough to replay from, something clean enough to trust, and something shaped for consumers. Whether all three are physical copies is a separate decision, and materialising all three by default is how platforms end up storing the same facts three times.
Yes, and often it should be. Materialise when the transformation is expensive and reused, when the layer needs its own retention or permissions, or when consumers need a stable published contract. Otherwise a view delivers the same guarantee without a copy that can drift.
No. It is a naming and layering convention, not a technology. It works on Apache Iceberg, on Delta, on Hudi, and on a cloud warehouse. The convention originated in the Databricks ecosystem, which is why it is often described alongside Delta.
As many as you have distinct guarantees, which is rarely more than three. Every additional layer is locally justifiable and collectively expensive. Adding a staging layer and a platinum layer usually signals that the existing layers are not delivering what their names promise.
Dimensional modelling if BI tooling is the main consumer, data vault if auditability is a hard requirement, domain-oriented ownership if your problem is organisational, or a semantic layer over fewer physical tables if you want to minimise copies. They are not mutually exclusive with medallion, and most real platforms mix them.
Only for replay, audit and debugging. Once dashboards read bronze, the raw layer has production consumers and you can no longer change it, which removes the thing that made it valuable.
For a deeper treatment of the table format underneath all of this, download Apache Iceberg: The Definitive Guide by Tomer Shiran, Jason Hughes, and Alex Merced, free from Dremio.
To see these ideas applied in practice, explore how Dremio approaches the open data lakehouse.
Deploy agentic analytics directly on Apache Iceberg data with no pipelines and no added overhead.
By unifying data from diverse sources, simplifying data operations, and providing powerful tools for data management, Dremio stands out as a comprehensive solution for modern data needs. Whether you are a data engineer, business analyst, or data scientist, harnessing the combined power of Dremio and Apache Iceberg will undoubtedly be a valuable asset in your data management toolkit.
Editor’s note, September 2026. This post was published in September 2023 and some product details have changed since. Nessie is still available and self-deployable under the Apache-2.0 licence, and it remains the clearest implementation of catalog-level branching. It is not an Apache Software Foundation project, and its development has slowed considerably. For how the current […]
This blog helps you learn about table-driven access policies in Dremio Cloud and Dremio Software v24.1+.
