Bronze, Silver, Gold: A Practical Guide to Medallion Architecture

Overview

In this episode of The Dashboard Effect, Brick Thompson and Landon Oaks walk through medallion architecture, a data organization pattern that has become a standard way to structure a lakehouse. The conversation breaks down how raw source data moves through distinct layers on its way to becoming something a business user can actually trust and query, and why that structure matters even for teams who have never heard the term before.

The hosts keep the explanation grounded in practical tradeoffs rather than abstract theory, including when to add a layer and when to skip one. See how Blue Margin’s Managed Data Service applies these architectural principles to build data pipelines that are both reliable and efficient for the organizations it serves.

What This Episode Covers

The Bronze Layer (0:43 – 1:31)

Bronze is the landing zone where source data arrives in its original form. If the data comes from Salesforce, this layer holds a one to one replica of that data, dirty or clean, exactly as it was received. The hosts explain that preserving this raw copy matters because it gives a team a reliable starting point to fall back on if something goes wrong downstream, rather than having to re-pull from the source system every time an error surfaces.

The Silver Layer (2:02 – 2:54)

Silver is where transformation happens. This is the stage for cleansing tasks like de-duplication, and for combining data from multiple sources, such as merging Salesforce and HubSpot into one unified format. The hosts are clear that this layer is optional rather than mandatory, and its presence depends on how much cleanup or blending the data actually needs.

The Gold Layer (2:58 – 3:23)

Gold is the analytics ready layer, where data is modeled into a structure like a star schema with dimensions and fact tables. This is the trusted layer that business intelligence tools like Power BI or Tableau pull from directly, which means the quality and structure of gold data has a direct effect on what end users see on their dashboards.

Keeping It Lean (1:47 – 2:54)

Landon makes the case against forcing every dataset through all three layers by default. When a transformation is simple, moving straight from bronze to gold avoids unnecessary architectural overhead and keeps the pipeline easier to maintain. The broader point is that medallion architecture is a framework to apply with judgment, not a rule that every dataset must satisfy regardless of complexity.

Views Versus Materialization (3:25 – 5:26)

The hosts explain their default preference for using views to reference data between layers, since views are performant and allow for fast iteration as requirements change. They reserve materialization, physically saving query results to disk, for datasets that are massive or unusually complex. That tradeoff comes with added responsibility, since materialized data introduces the need to manage deletions, updates, and inserts rather than simply reflecting the source in real time.

Who It’s For

This episode is worth your time if you are a data engineer designing or refining a lakehouse structure, an analytics leader trying to understand why your reporting layer is organized the way it is, a technical stakeholder evaluating a data platform build for your organization, or anyone who wants a clear, practical explanation of medallion architecture without wading through vendor marketing.

Why It’s Worth a Listen

The most useful idea in this episode is that medallion architecture is not a rigid checklist. Brick and Landon are explicit that the silver layer is optional and that bronze to gold is a legitimate path when the data does not need heavy transformation. That distinction saves teams from building unnecessary complexity into pipelines that do not need it.

The views versus materialization discussion is equally practical. Defaulting to views keeps a data platform flexible and fast to iterate on, while reserving materialization for genuinely large or complex datasets acknowledges the real cost of that choice, including the added work of handling deletions, updates, and inserts correctly.

Taken together, the episode offers a working mental model for anyone trying to evaluate whether their own data platform is over engineered, under built, or right sized for what the business actually needs.

Get Expert Insights in Your Inbox

To subscribe, submit the short form below.