Medallion Architecture Explained: Bronze, Silver and Gold

Medallion Architecture is a way to improve the quality and usability of data step by step as it moves through a platform. Data arrives roughly as the source produced it, is then cleaned and conformed into dependable entities, and is finally shaped for the people and applications that consume it. The three stages are usually called Bronze, Silver and Gold.

It is worth being precise about what the pattern is. Medallion Architecture is a design pattern, not a product feature. The term comes from the lakehouse community, and Microsoft’s Fabric documentation describes it as a recommended approach for Lakehouses, but nothing in Microsoft Fabric requires it, enforces it, or behaves differently because a table lives in something called “Silver”. A Lakehouse named bronze is an ordinary Lakehouse.

That distinction matters because the pattern is easy to apply mechanically. Three layers become three copies of every table, three sets of pipelines and three places where things can break, whether or not each copy adds anything. This article explains what each layer is for, how quality and incremental processing work across the layers, and how to decide when fewer layers are the better design.

The basic flow

1. SourcesApplications, files, APIs, databases
2. BronzeLand the data as received
3. SilverClean, validate, conform
4. GoldShape for a business use
5. ConsumersReports, models, APIs

• Sources are the systems the platform does not control: operational databases, SaaS applications, partner files, event streams.
• Bronze captures what the source delivered, with enough metadata to trace and replay it.
• Silver turns source-shaped records into clean, validated, conformed entities that several downstream uses can trust.
• Gold shapes those entities for specific business processes: a reporting model, a set of aggregates, a table behind an API.
• Consumers read Gold, and occasionally Silver, but never Bronze.

The value is in the boundaries. Each arrow is a point where a defined transformation happens, where quality can be checked, and where a failure can be isolated without corrupting the next layer.

• Bronze

  Source-aligned

  • Raw or minimally transformed
  • Auditable and replayable
  • Shaped like the source
  • Append-heavy

• Silver

  Enterprise-aligned

  • Clean and validated
  • Deduplicated
  • Conformed entities and keys
  • Reusable by many consumers

• Gold

  Consumer-aligned

  • Business-ready
  • Modelled or aggregated
  • Optimized for serving
  • Owned with a consumer in mind

Bronze layer

Bronze holds raw or minimally transformed data. Its job is source fidelity: when someone asks what a system actually sent on a given day, Bronze should be able to answer.

Minimal transformation means converting to a queryable format, typically a Delta table, and adding metadata. It does not mean fixing values, renaming columns to business terms, or filtering records that look wrong. Every correction made here removes evidence that may be needed later.

Ingestion metadata is what makes Bronze useful rather than merely large. Useful columns include the load timestamp, a batch or run identifier, the source system, and the source file name or extraction window. With them, a bad batch can be identified and reprocessed, and any Silver row can be traced back to the input that produced it.

That traceability is the basis of auditability. Bronze is often where retention requirements are met, and where a pipeline can be replayed after a bug in later logic is fixed, without asking the source system to send everything again.

Bronze also absorbs schema drift. Sources add columns, change types, or send malformed files. A tolerant Bronze layer can land that data, for example by allowing additive schema changes or keeping a raw payload column, and leave the decision about what the change means to the Silver logic. That is better than failing ingestion and losing the data.

Bronze workloads are append-heavy. New data is added; existing data is rarely changed. This makes Bronze simple to write and cheap to load, and it fits Delta tables well. Source file formats such as CSV, JSON or Parquet can be kept as files in the Lakehouse Files area for full fidelity, loaded into Bronze Delta tables, or both. Keeping the original files is useful when the format conversion itself might be lossy.

When Bronze is not necessary. If the source is already a durable, queryable, versioned system that can be re-read on demand, and nobody needs the history of what was received, a separate raw copy may add little. Some platforms also land data directly into a cleaned table when the source is trusted and the transformation is trivial. Bronze earns its place when replay, audit, or tolerance to messy input matters.

Silver layer

Silver is where data becomes dependable. The typical work is:

• Cleaning: trimming, fixing encodings, handling nulls and sentinel values.
• Validation: rejecting or quarantining records that break rules, instead of passing them on silently.
• Deduplication: removing repeated deliveries and keeping the latest version of each record.
• Standardization: consistent types, time zones, units, currencies and code values.
• Conformance: shaping data into shared conformed entities such as customer, product or order, so that data from several sources lines up.
• Joins that are technical rather than business-specific, for example resolving lookup codes or attaching reference data.

Business keys become central in Silver. Bronze records are identified by source and batch; Silver entities are identified by keys that mean something across systems, such as a customer number or an order ID. Choosing and enforcing those keys is what makes deduplication, MERGE and change tracking possible.

Data quality rules belong here as explicit, testable checks: uniqueness of keys, required fields, valid ranges, referential integrity with reference data. Records that fail can be routed to a quarantine table with the reason, so problems are visible instead of disappearing.

The outcome is a set of reusable curated datasets. Silver is not built for one report. It is the layer that several Gold models, data science work and ad-hoc analysis can share, which is where most of its value comes from.

Gold layer

Gold is business-facing. Its tables exist because a known consumer needs them:

• Reporting: facts and dimensions behind dashboards and paginated reports.
• Semantic models: Power BI models, including Direct Lake models that read Delta tables in OneLake.
• APIs: narrow, stable tables or views that an application queries.
• Aggregates: pre-computed totals where computing them at query time would be too slow or too costly.

Dimensional models are the most common Gold shape, because they are understandable to analysts and work well with BI tools. Wide denormalized tables are also legitimate when a single consumer needs them.

Gold tables are performance-focused serving tables. They are designed around how they are read: which columns are filtered, which grain is needed, how fresh the data must be. Unlike Silver, a Gold table can reasonably be built for one purpose, as long as someone owns it and knows who consumes it.

Do you always need three layers?

No. The number of layers should follow the problems you need to solve, not the diagram.

• Simple workload

  One trusted source, one consumer

  1. Source
  2. →Curated
  3. →Consumer

  Enough when the source is reliable, the transformation is small, and no one needs raw history.

• Complex workload

  Many sources, many consumers

  1. Source
  2. →Bronze
  3. →Silver
  4. →Gold
  5. →Consumer

  Justified by replay and audit needs, cross-source conformance, and several consumer-specific models.

Common cases where fewer layers are enough:

• Bronze + Gold. A single source feeds a single reporting model, and the cleaning is minor. The cleanup can happen in the step that builds Gold, and a separate Silver copy would only duplicate the data.
• Silver + Gold. The source is already clean and versioned, for example a well-governed operational database read through change tracking. Landing an untouched copy first may add storage and latency without adding auditability.
• A direct curated model. A small team, a few trusted sources and one Lakehouse or Warehouse with clearly named curated tables can be the right design. A clear model with tests is better than three thin layers.

Extra layers create real cost: more storage, more compute for each pass, longer end-to-end latency, more pipelines to deploy and monitor, and more places where definitions can drift. A layer is justified when it creates a contract that something depends on: retained input for replay, conformance shared across domains, isolation of sensitive fields, or several consumers with different needs.

Delta tables and Medallion

In Fabric, Lakehouse tables and Warehouse tables are stored as Delta tables in OneLake. Delta brings several properties that make layered processing practical:

• ACID transactions on each table, so readers never see a half-written batch.
• MERGE for upserts and deletes, which is how most Silver tables absorb changes.
• Schema enforcement and evolution, which helps Bronze tolerate additive changes while Silver stays strict.
• Incremental processing support, including the change data feed where it is enabled, so later layers can read only what changed.
• Transaction history and time travel, useful for audit and for recovering from a bad write.

Delta does not design the layers for you. Transactions are per table, so a pipeline that writes several tables still needs its own logic for consistency and restartability. MERGE on large tables can be expensive if the match condition cannot narrow which files are touched. Time travel depends on retention settings and maintenance. Delta makes the pattern workable; the boundaries and the logic are still engineering decisions.

Incremental processing

1. New source dataSince the last watermark
2. Bronze appendNew batch, with metadata
3. Silver changed recordsMERGE by business key
4. Gold affected aggregatesRecompute only impacted slices

A full reload rebuilds every table from scratch on each run. That is simple and works while data is small. As volumes grow, the cost grows with the total size of the data rather than with the size of the change. Runs take longer, compete for capacity, and the window in which a failure can happen grows with them.

Incremental processing scales with the change instead. Bronze appends the new batch. Silver identifies the affected business keys and merges only those records. Gold recomputes only the aggregates whose inputs changed, such as the days, stores or customers touched by the batch.

The difficult parts are correctness rather than speed: late-arriving data, deletes in the source, re-sent batches, and keeping a reliable watermark. Incremental pipelines should be idempotent, so that rerunning a batch produces the same result, and they benefit from a periodic reconciliation against a full recount.

Partitioning

Partitioning splits a table into folders by the value of a column, so queries that filter on that column can skip the rest. In layered platforms it is often applied too early and too widely.

• Partition only when justified. Small and medium tables are usually faster without partitions. Databricks, for example, recommends not partitioning tables smaller than about a terabyte, and keeping each partition at around a gigabyte or more.
• Avoid high-cardinality keys. Partitioning by customer ID or by timestamp produces thousands of tiny partitions and many small files.
• Date or time partitions at a coarse grain, such as month or day, are the usual sensible choice for large append-heavy tables, especially in Bronze where data arrives by load date.
• Pruning only works if queries filter on the partition column. A Gold table partitioned by load date but queried by business date gains nothing.
• Every partition adds files. More partitions mean more, smaller files, so partitioning always trades pruning against file count.

Partitioning choices can differ by layer: load date may suit Bronze, business date may suit a large Silver fact, and most Gold tables are small enough not to need partitions at all.

Small files

Delta tables are made of Parquet files, and every file has a cost: it must be listed, opened and read, and its metadata must be tracked in the transaction log. Frequent small appends, streaming ingestion, over-partitioning and many small MERGE operations all create large numbers of small files.

The symptoms are slow queries even on modest data, growing transaction logs, and slower writes. The remedy is compaction: periodically rewriting many small files into fewer, larger ones. In Fabric this is done with OPTIMIZE from Spark or with the Lakehouse table maintenance feature, and Fabric can also apply V-Order to improve read performance. Compaction is followed by VACUUM to remove files that are no longer referenced, within the retention period you need for time travel.

Different layers produce small files for different reasons, so maintenance should be scheduled per table rather than applied blindly everywhere.

Data quality

Quality expectations change as data moves through the layers. Each layer answers a different question.

1. CompletenessBronzeDid we receive the data?
2. ValiditySilverIs the data valid and consistent?
3. Fitness for useGoldIs the data correct for the business use case?

• Bronze checks arrival: the expected files or extracts arrived, row counts are plausible, and the schema is readable. It does not judge the values.
• Silver checks validity: keys are unique, required fields are present, values are in range, codes resolve, and duplicates are removed. Failing records are quarantined with a reason.
• Gold checks business correctness: totals reconcile with a known source, measures behave as expected over time, and the grain matches what consumers assume.

Checks between layers act as gates. A batch that fails Silver validation should not quietly flow into Gold reports.

Example Fabric architecture

1. Sources

   • Operational databases
   • Files
   • APIs

2. Ingestion

   • Data pipeline
   • Notebook

3. Bronze

   • Bronze LakehouseRaw Delta tables and files

4. Transformation

   • NotebooksClean, validate, deduplicate

5. Silver

   • Silver Delta tablesConformed entities

6. Business transformations

   • Notebooks or T-SQLModel and aggregate

7. Gold

   • Gold Lakehouse or WarehouseFacts, dimensions, serving tables

8. Serving

   • SQL analytics endpoint
   • Semantic model
   • API
   • Reports

Cross-cutting concerns

• Git integration
• Deployment pipelines
• Run logging
• Monitoring
• Workspace security

A few implementation notes:

• Data pipelines are well suited to copying data in and orchestrating steps; notebooks are well suited to transformation logic. Many platforms use pipelines to call notebooks.
• Separate Lakehouses per layer make permissions and ownership clearer, but a single Lakehouse with clear naming can be enough for a small platform.
• Gold can be a Lakehouse when transformations are written in Spark, or a Fabric Warehouse when the team prefers T-SQL and needs multi-table transactions. The SQL analytics endpoint of a Lakehouse is read-only, so writes go through Spark.
• Logging, monitoring, Git and deployment are not layers, but every layer depends on them.

Common mistakes

• Blindly creating three layers because the pattern says so, rather than because each layer has a purpose.
• Duplicating data without a reason, such as Silver tables that are byte-for-byte copies of Bronze.
• Mixing raw and curated data in the same tables or Lakehouse without clear naming, so consumers read unvalidated data by accident.
• Placing business logic in Bronze, which destroys source fidelity and makes replay impossible.
• Over-partitioning, especially by high-cardinality columns, which creates small files and slows everything down.
• Rebuilding entire tables unnecessarily on every run once data volumes no longer allow it.
• Creating a Gold table for every possible report, which turns Gold into an unowned collection of near-duplicates.
• No quality checks between layers, so problems travel all the way to reports before anyone notices.
• No observability: no run log, no row counts, no freshness tracking, and therefore no fast way to tell which layer failed.

Closing thoughts

Medallion Architecture is valuable when each layer has a clear purpose and an operational boundary: a defined input, a defined transformation, a quality gate, and an owner. Used that way, it makes platforms easier to trust, debug and change. Used as a fixed template, it multiplies storage, pipelines and failure points without improving the data.

Start from the problems you need to solve, such as replay, conformance across sources, serving performance or isolation, and add a layer when it solves one of them.

The Medallion Architecture section of the Fabric learning path continues with dedicated articles. Several are planned and can be followed in the editorial roadmap:

• Delta MERGE patterns in a Medallion architecture
• Incremental processing across Bronze, Silver and Gold
• Partitioning strategies across layers
• Small files and compaction
• Fabric pipelines