Medallion Architecture Explained With a Real Snowflake Migration

The pattern became popular with lakehouse platforms, but it works on any modern data warehouse, including Snowflake. Its value is practical: when a dashboard shows a strange number, the team can follow it back through the layers, find where it changed and fix the rule without reloading data from every source system.

In a medallion architecture, raw data is never edited in place, each layer has one job and every transformation between layers is repeatable, which makes data quality measurable and errors fixable at their source.

This article explains what each layer does, the design decisions to make early and how the pattern works on Snowflake, Databricks and Microsoft Fabric, using a real migration of marketing and event data as the main example. It is not a step-by-step tutorial for one platform, and it does not cover real-time streaming architectures in depth.

Key takeaways

• Bronze keeps source data unchanged with load metadata, silver cleans and standardizes it, and gold shapes it for specific reports and applications.
• Keeping raw data intact lets a team reprocess history when a cleaning rule changes, without going back to the source systems.
• Data quality becomes measurable between layers: share of values changed, distribution before and after, and completeness per field.
• On Snowflake, the layers are usually separate schemas or databases, loaded with stored procedures, tasks or dynamic tables.
• In a real migration of marketing data, standardized CRM fields reached 93.4% to 99.7% coverage once cleaning rules moved into a dedicated silver layer.
• Most medallion projects fail on naming, ownership and testing, not on technology.

The three layers at a glance

Databricks, which popularized the term, describes the medallion architecture as a way to incrementally improve the structure and quality of data as it moves through the layers. It is sometimes also called a multi-hop architecture.

Bronze: keep everything, change nothing

The bronze layer is a faithful copy of each source. Tables mirror the source structure, and the pipeline adds only metadata such as when the record was loaded, from which system and in which batch. Nothing is cleaned or removed here, because the whole point is to have an untouched starting point that can be reprocessed.

Silver: one clean version of the truth

The silver layer turns raw records into consistent entities, such as contacts, companies, events and registrations. This is where duplicates are removed, formats are standardized and values from different systems are mapped to one shared list. Silver tables are not built for a single report. They are the reusable foundation for all of them.

Gold: shaped for a purpose

The gold layer holds tables designed for specific uses: a revenue dashboard, an audience segment for a marketing platform or a dataset for a machine learning model. Gold tables are usually denormalized and read-optimized, so reports run fast and business users do not need to write complex joins.

Why the layers matter

Lineage you can follow

When a number in a report looks wrong, the team can trace it from gold to silver to bronze and see exactly where it changed. Without layers, the same investigation often means reading through nested SQL and asking the source system's owner what happened.

Reprocessing without reloading

Cleaning rules change. A new value appears in a dropdown, a vendor renames a field or the business redefines a segment. Because bronze holds the original data, the team updates the rule and rebuilds silver and gold from history, without extracting everything again from the source systems.

Measurable data quality

Each step between layers is a place to measure. Teams can track how many values a rule changed, how distributions shifted and how complete each field is, and they can alert when those numbers move unexpectedly.

Clear ownership

Each layer has an owner and a contract. Engineers own bronze and silver, analysts or domain teams own gold, and changes to silver are reviewed because many gold tables depend on them.

A real migration: marketing and event data on Snowflake

A US cybersecurity media and events company runs a marketing and events stack that feeds Snowflake for reporting and audience segmentation in Marketo. Data came from Google Analytics 4, the webinar platform ON24, the event platform Swoogo, WordPress and Monday.com, alongside Salesforce and Marketo themselves.

The starting point

• No standard ingestion layers. Data from each source landed in legacy tables with their own structure, which made new sources slow to add.
• Duplicate formats. The same attribute appeared in different forms across Salesforce and Marketo, such as different spellings of industries and different ranges for company size.
• Missing values. Many key fields were empty, which undermined trust in reporting and made audience segments unreliable.

Two .wrk data engineers joined the client's marketing operations team through staff augmentation, working with a marketing operations liaison on the business rules.

Building the bronze layer

The engineers designed a raw bronze layer for each source and migrated the existing legacy tables into it, so historical data was preserved in its original form. Stored procedures handled incremental loads, picking up only new and changed records, and GitHub Actions orchestrated the pipeline runs for repeatable, logged execution.

Building the silver layer

The silver layer is where the real business value appeared. The team focused on four fields that drive segmentation and reporting: lead role, revenue, company size and industry.

• Normalization buckets. Each field received a defined list of standard values, and rules mapped the many raw variations into those buckets.
• Explicit handling of uncertain values. Values that could not be classified with confidence went into a TBD or ambiguous bucket instead of being forced into the wrong category. This kept errors visible and made them easy to review.
• Enrichment from several sources. When one system had a missing value, the pipeline filled it from another source where possible, and backfilled history the same way.

Measuring every change

Every rule run was tracked with delta metrics: the share of values changed, the distribution of values before and after and the completeness of each field. Dashboards showed these data quality indicators to the marketing operations team, so business users could see the effect of each rule instead of taking it on trust.

Results

After the migration, coverage of standardized values reached 99.7% for lead role, 96.4% for company size, 95.9% for industry and 93.4% for revenue. Marketo segments could finally reflect what sales teams had entered in Salesforce, and the platform was ready to scale to new sources and downstream reporting. Read the data platform case study.

Where gold fits in a setup like this

In this project, the immediate consumers were Marketo segments and data quality dashboards built on the cleaned data. As reporting grows, those consumers become formal gold tables: audience segments with documented definitions, event attendance and engagement summaries, and revenue and pipeline views by industry and company size. Building silver first meant each new gold table could reuse the same clean entities.

Medallion architecture on Snowflake, Databricks and Fabric

The pattern is the same everywhere. The building blocks differ by platform.

Snowflake

Layers are usually separate databases or schemas, such as RAW, CLEAN and MART, with access controlled per layer. Loads can run as stored procedures called by an orchestrator, as Snowflake tasks, or as streams that capture changes for incremental processing. Dynamic tables let a team declare a layer as a query with a target lag, and Snowflake works out refresh order and incremental updates. Dynamic tables suit multi-step transformations but not data that must be fresher than about a minute.

Databricks

Layers are Delta tables, often in separate schemas within Unity Catalog. Lakeflow Declarative Pipelines, formerly Delta Live Tables, define streaming tables and materialized views with built-in data quality expectations, which makes them a natural fit for bronze to silver rules.

Microsoft Fabric

Microsoft recommends a separate lakehouse for each layer, ideally in its own workspace, for clearer governance per layer. Its guidance on medallion architecture in Fabric describes bronze as data stored exactly as it arrives, silver as fixed and standardized data and gold as data organized for reports.

Choosing between them

The choice usually follows the platform a company already has. Snowflake suits SQL-first teams with structured business data such as CRM, marketing and finance. Databricks suits teams with heavy data science, semi-structured data or streaming. Fabric suits organizations standardized on Microsoft tools and Power BI.

Design decisions to make early

1. Naming and structure. Decide on database, schema and table naming for each layer before the first load, such as raw_salesforce_contacts and clean_contacts. Renaming later breaks every dependency.
2. Metadata columns. Add load timestamp, source system and batch identifier to every bronze record. They make debugging and reprocessing possible.
3. Incremental loading. Decide how each source identifies new and changed records, such as updated timestamps, change data capture or full snapshots with comparison.
4. Idempotent pipelines. Running the same load twice should not create duplicates. Use merge logic and processing logs.
5. History in silver. Decide which entities need history, for example when a contact changes company, and store it with effective dates.
6. Handling uncertain values. Define an explicit bucket for values that cannot be classified, as in the project above, instead of guessing.
7. Personal data. Bronze holds raw personal data, so restrict access to it, mask sensitive fields in silver where possible and define retention periods.
8. Testing. Add tests for uniqueness, accepted values, null rates and row counts between layers, and run them on every change.
9. Orchestration and logging. Use one orchestrator, such as GitHub Actions, Airflow, dbt Cloud or native platform scheduling, and log every run.

Common mistakes

• Cleaning data in bronze. Once raw data is altered, it can no longer be reprocessed when a rule changes.
• Building gold straight from bronze. Every report then repeats its own cleaning logic, and numbers disagree between dashboards.
• Too many layers. Some teams add platinum, staging and intermediate layers until nobody knows which table to use. Three layers with clear contracts are usually enough.
• No owner for silver. Silver is shared by everyone, so it needs a clear owner who reviews changes.
• Measuring nothing. Without delta and completeness metrics, the business cannot see whether the new platform is better than the old one.

Medallion vs lakehouse vs data vault

These terms are often confused because they describe different things.

• A lakehouse is a platform design that combines cheap, open storage with warehouse features such as transactions and SQL. Medallion architecture is a common way to organize data inside a lakehouse.
• Medallion architecture is a layering pattern. It says how data moves from raw to refined, not how tables are modeled.
• Data vault is a modeling method for integrating data from many sources with full history. It can be used inside the silver layer of a medallion architecture.

How long a medallion migration takes

For a mid-size company with five to eight sources and a few critical business entities, a medallion migration typically takes two to four months with two data engineers, working alongside someone who owns the business rules. The bronze layer is usually the quickest part. Most of the time goes into silver: agreeing on standard values, handling exceptions and proving with metrics that the new data is better than the old.

Our guide to what staff augmentation is explains how data engineers can join an existing team for a project like this.