What Is Medallion Architecture? Bronze, Silver, and Gold Layers Explained

Medallion architecture vs. traditional ETL pipelines

In data warehouses with traditional extract-transform-load (ETL) pipelines, you have to define the schema of your data up front. If your data format or schema changes, the system will fail unless you manually adjust it. 

In a medallion-based extract-load-transform (ELT) architecture, you save the data in its raw form first, rather than transforming it on the fly and storing the final data. This difference makes medallion-based architectures both robust and flexible: you can store raw data as-is and decide how to use it later. 

For a full comparison of the two concepts, I recommend reading our ETL vs ELT guide.

Another advantage of the medallion architecture is its platform-agnostic nature. Bronze, Silver, and Gold are logical stages, not technologies tied to a particular vendor. You can implement the pattern with different storage systems, processing engines, and table formats, depending on your data platform and workload requirements.

How Do the Bronze, Silver, and Gold Layers In a Medallion Architecture Work?

The three medallion layers follow logically, each building on the previous.

Bronze layer: raw data as the recovery point

This is where the raw data lands as it is, whether that’s relational databases, SaaS applications like Salesforce, Kafka topics carrying real-time events, REST APIs, CSV exports, or IoT device streams. Ingestion is usually handled by tools such as Fivetran for change data capture or Databricks Auto Loader for files landing in object storage.

Bronze data typically contains quite a few errors, inconsistencies, and duplicates, so it should never be used directly for business purposes. That said, the layer is very valuable as a recovery point from which you can regenerate Silver or Gold data.

The importance of the layer lies in its footprint: it records and logs every ingestion event or transaction. It often contains valuable metadata, such as ingestion timestamps, data origins, and various kinds of identifiers. The goal is to store the data as raw and complete as possible, so you can replay downstream pipelines using the same source data to debug any bugs.

Silver layer: the contract layer

The silver layer transforms raw data into clean, structured data. A few examples of the important cleaning transformations taking place between Bronze and Silver levels:

• Filtering out unnecessary columns
• Deduplicating records
• Fixing inconsistencies
• Handling missing values
• Standardizing the data
• Joining and merging various datasets

This layer also contains schema enforcement, ensuring the data meets pre-defined structure and supports schema evolution. 

You also handle data quality checks here. For example, add rules to flag or reject failed business transactions or outliers. This is the first step to improve the data quality as the data passes through stages.

Since this stage involves data modification, it's important to use data lineage tools like dbt to track how data is transformed from Bronze to Silver. Quality checks are typically implemented with dbt tests, Great Expectations, or Soda, while governance is enforced through a data catalog such as Databricks Unity Catalog or Collibra.

If you want to learn how to turn messy data into proper silver datasets, I recommend starting with our Cleaning Data in Python course.

Gold layer: business-ready outputs

The final layer of the architecture stores the data at the highest possible quality. This highly refined data is used for business reporting in Power BI, Tableau, or Looker, consumed by downstream analytical applications, or served to machine learning models via a feature store such as Feast or Databricks Feature Store.

Since the data is already cleaned, this stage focuses on turning it into a valuable business asset. Depending on the specific use case in mind (think of financial reports, marketing dashboards, alert systems, ML model training, …), the transformations after Silver ensure that Gold contains exactly the information needed for the task at hand.

Here you create KPIs, apply custom business formulas, or aggregate to weekly, monthly, or quarterly data for scheduled reporting. While the Bronze and Silver operations are often common, Gold layer operations are more flexible and custom to how you want to use this data.

How Do You Rebuild Silver and Gold From Bronze Data?

Preserving raw data in Bronze only pays off if you can actually use it, and that happens whenever something upstream or downstream changes. The cost of a change depends on how far along the chain it sits. 

• A source schema change means replaying Bronze through both Silver and Gold. 
• A change to a business definition (e.g., a new revenue rule or a different aggregation window) only means rebuilding Gold from Silver that has already been validated.

In neither case do you go back to the source system. That's what makes historical corrections possible at all, since the source may no longer hold the data in the form you originally ingested it. 

It also means you can change a metric definition without re-running ingestion, which is the practical reason teams with many Gold consumers keep the layers separate.

Where Does Medallion Architecture Fit in a Data Lakehouse?

A data lakehouse gives you the cheap object storage of a data lake with the transactional guarantees of a warehouse. It says nothing about how to arrange the tables inside it. That is the gap medallion fills: the lakehouse is the storage substrate, and Bronze, Silver, and Gold are how you divide it into catalogs, schemas, and tables with different quality guarantees.

In practice, that division is usually physical. On Databricks, you might have three schemas in a Unity Catalog catalog, and in Microsoft Fabric, a lakehouse with Bronze and Silver tables feeding a Gold warehouse. Same pattern, different plumbing.

Open table formats are what make the layers hold up under concurrent reads and writes. Delta Lake, Apache Iceberg, and Apache Hudi each offer some combination of:

• ACID transactions
• Schema evolution
• Versioned table state
• Concurrency controls
• Partition evolution
• Time travel

The versioning matters most for the replay behavior we just covered. Raw Parquet files preserve your source data fine, but they give you no transactional history to roll back to, so a bad Silver run overwrites the good one, and you have nothing to compare against. Delta Lake tracks changes in a transaction log, while Apache Iceberg represents table states as snapshots.

None of this is mandatory. Medallion is a logical pattern, and plenty of teams run it on Postgres schemas or plain S3 prefixes with dbt on top. You just lose the cheap rollback.

Medallion architecture vs data mesh

These two get compared a lot, usually because people assume they compete. They answer different questions: data mesh decides who owns data, and the medallion architecture decides how that owner refines it.

Data mesh hands responsibility for data to domain teams like sales, finance, or supply chain, who publish their data as products and own its quality, discoverability, lineage, and governance. Two things hold that together: self-service infrastructure that gives every domain the same tooling, and federated governance that sets organization-wide standards without taking ownership away from domains.

Medallion architecture is what a domain team runs inside its own slice. A supply chain team owning shipment data keeps raw shipment events in Bronze, validated records in Silver, and publishes analytics-ready shipment datasets in Gold for other domains to consume. The mesh defines the contract at the Gold boundary; everything upstream of it is that team's business.

One caveat before you combine them: per-domain Bronze layers mean each domain carries its own ingestion and storage cost, and shared dimensions like customer or product tend to get rebuilt in three places. Mesh advocates would say that's the price of ownership. It's still a real cost, and worth pricing before you commit.

What Are the Benefits and Limitations of Medallion Architecture?

Medallion buys you reuse and recoverability, and charges you for storage, latency, and pipeline count. Whether that trade works out depends almost entirely on how many consumers you have.

The latency one is the easiest to underestimate. Each layer is usually its own scheduled job, so a three-layer batch pipeline running hourly can leave Gold two hours behind the source system. That's fine for a weekly revenue report and not fine for an operational alert, which is why teams often let alerting read Silver directly rather than waiting for Gold.

Storage is the cost people raise first, and it's usually the smaller problem. Bronze sits in cheap object storage, and the duplication is real but bounded. The pipeline count is what actually hurts: three layers across twenty source tables is sixty things that can potentially fail at 3 am.

Set against that, poor data quality has its own bill. IBM reported in 2026 that 43% of COOs named data quality as their most significant data priority, based on 2025 research from its Institute for Business Value. More than a quarter of organizations in that study reported annual losses from poor data quality exceeding $5 million.

So the question isn't whether implementing a medallion architecture costs more than a single pipeline, because it does. The question is whether you're already paying for the alternative in reconciliation meetings and dashboards nobody trusts.

When Should You Use Medallion Architecture?

Medallion earns its keep when the same cleaned data serves more than one consumer. That's the single best predictor, ahead of data volume, team size, or how many sources you pull from.

Use medallion architecture when:

• Multiple teams or workloads read the same data. Clean and standardize once in Silver, then build as many Gold datasets on top as you need for BI, reporting, or model training.
• Different business questions need different shapes of the same data. Finance wants monthly recognized revenue, and sales wants daily bookings by rep. Both come off one Silver table without duplicating ingestion logic.
• Your sources disagree with each other. Silver is where you reconcile a Salesforce account ID against a billing system's customer ID before anyone downstream has to guess which is authoritative.
• You need to answer for a number. Separating raw, validated, and curated data means you can walk a disputed figure back through each transformation instead of re-deriving it from scratch.
• Transformation logic changes often. As covered above, preserved Bronze data is what lets you rebuild without going back to the source.

Skip it when:

• You have a small data team and limited pipeline complexity.
• Data comes from a single source with minimal cleaning or transformation.
• Only one downstream application or team consumes the data.
• Your reporting requirements are straightforward and don't justify maintaining multiple processing layers.

When two layers are enough

The three-layer diagram is a default, not a requirement. With a single business use case, Bronze plus one combined layer is often the right call: preserve raw data for replay, then do cleaning and business logic in one step.

Pick the shape that matches your consumers. What you shouldn't collapse is Bronze, because that's the layer you can't recreate.

So if you're in the middle and honestly can't tell, building two layers and adding the third when a second consumer shows up is a good way to go. Adding Gold later is much cheaper than retrofitting Bronze after you've been overwriting your raw data for the last six months.

Common Mistakes in Medallion Implementations

Most medallion problems aren't architectural. They're small compromises made under deadline pressure that quietly remove the reason you built the layers in the first place.

Data transformation in Bronze

The whole replay argument rests on Bronze holding something close to what the source actually sent. Apply business logic before you land it, and you've lost the original state, which means no reprocessing and no audit trail.

This usually happens for good reasons. Someone drops a column nobody uses to save space, or coerces a messy timestamp field at ingestion because it breaks the next job. Six months later, the unused column turns out to matter, and the original values are gone. Keep Bronze as close to the source as you can practically manage, and put the fixes in Silver.

Blurring the Silver and Gold boundary

Silver cleans and standardizes. Gold answers business questions. When metric logic leaks into Silver, every Gold dataset inherits a definition it didn't ask for, and you're back to the problem medallion was supposed to solve.

The test is simple: if a business user argues about the number, it belongs in Gold. Deduplication is a Silver concern. What counts as an active customer is not.

Treating three layers as mandatory

Medallion architecture is a logical design pattern, not a requirement that every pipeline contain exactly three physical layers. Bronze, Silver, and Gold represent logical stages of data refinement, and each layer can be implemented differently depending on the workload. 

For example, a layer might use materialized tables, views, or other appropriate abstractions rather than requiring a separate physical copy of the data. The point is to create meaningful boundaries as data moves from its raw state toward something the business can trust and use, rather than to reproduce the classic three-layer diagram exactly. 

Leaving Gold as a dumping ground

This is the one I see most, and it gets discussed least. Gold datasets are cheap to create, and nobody ever deletes them, so after a year, you might have forty tables, eleven of them variations on monthly revenue, and no one remembers which the CFO actually looks at.

Silver has natural discipline because its job is defined. Gold doesn't, so it needs an owner per dataset and a willingness to delete. Without that, you end up with several competing versions of the same metric, which is one problem the layers were supposed to prevent.

Final Thoughts

What medallion actually gives you is a place to point at when someone asks where a number came from, and a copy of the original data to go back to when the answer turns out to be wrong. That's worth the extra storage and the extra jobs when several teams read the same data. When only one team does, two layers might be the better solution and save you some maintenance.

If you want the wider context around where this pattern sits, our Understanding Modern Data Architecture course covers the platforms and technologies behind modern data stacks. Our Data Engineer career track goes further into building and maintaining production pipelines.