Medallion Architecture for Data Analytics: A Practical Guide to Building Trusted Data Products

A practical guide to designing Bronze, Silver, and Gold data layers for reliable analytics, trusted dashboards, and real-world data products.

Photo by Alexandr Popadin on Unsplash

Modern analytics rarely fails because companies do not have enough data.

It fails because the same business question produces five different answers.

• Finance says yesterday’s revenue was $1.2M.
• Marketing says it was $1.4M.
• The executive dashboard says $1.1M.
• Meanwhile, the data science team quietly exports a CSV from another system because the warehouse table “looks suspicious.”

Somewhere in the middle of this chaos, a data engineer is trying to explain:

• Why a late-arriving order changed yesterday’s number
• Why a refund was counted twice
• Why one customer exists under three different IDs
• Why a dashboard still uses old revenue logic
• Why nobody knows which table is the official one

This is exactly the kind of problem Medallion Architecture is designed to solve.

Medallion Architecture organizes data into progressive quality layers:

• Bronze — raw data
• Silver — cleaned and validated data
• Gold — business-ready analytical data

The goal is simple:

Move data from raw evidence to trusted business insight in a controlled, traceable, and reusable way.

What Is Medallion Architecture?

Medallion Architecture is a layered data design pattern commonly used in modern lakehouse and analytics platforms.

The core idea is that data becomes more reliable and more useful as it moves through each layer.

Sources
  ↓
Bronze Layer
  Raw, source-faithful data
  ↓
Silver Layer
  Cleaned, validated, standardized data
  ↓
Gold Layer
  Business-ready data for analytics, dashboards, and ML

Each layer has a clear responsibility.

LayerPurposeMain UsersBronzePreserve raw source dataData engineers, platform teamsSilverClean and standardize dataData engineers, analytics engineers, analystsGoldServe business use casesBusiness users, BI tools, data science teams

The naming is not the important part.

The discipline is.

Bronze, Silver, and Gold help teams separate:

• Raw ingestion
• Data cleaning
• Business logic
• Reporting logic
• Machine learning features
• Governance and access control

That separation is what creates trust.

The Mental Model: Evidence, Records, and Decisions

A simple way to understand Medallion Architecture is this:

Bronze: Raw Evidence

Bronze answers:

What exactly arrived from the source system?

It preserves the original data as faithfully as possible.

Silver: Clean Business Records

Silver answers:

What actually happened after cleaning, deduplication, validation, and standardization?

It turns messy source data into reliable entities and events.

Gold: Business Decisions

Gold answers:

What should dashboards, analysts, executives, and models consume?

It turns clean data into business-ready products.

Real-World Example: E-Commerce Analytics

Imagine an e-commerce company.

It receives data from:

• Orders database
• Payment provider
• Customer relationship management system
• Website clickstream events
• Marketing platforms
• Inventory system
• Product catalog
• Refund system

Without a clear architecture, every team may build its own version of the truth.

For example:

• Marketing calculates revenue from campaign conversions.
• Finance calculates revenue from payment settlement.
• Product calculates revenue from completed orders.
• Operations calculates revenue after cancellations and refunds.

All of them may be partially right.

But the business needs one trusted answer.

Medallion Architecture creates a controlled journey from raw data to trusted reporting.

Raw order events
  ↓
Bronze raw_orders
  ↓
Silver cleaned_orders
  ↓
Gold daily_revenue_dashboard

Bronze Layer: Preserve the Raw Truth

The Bronze layer is where data lands first.

It should be:

• Raw
• Complete
• Append-friendly
• Auditable
• Replayable
• Close to the original source

Bronze is not where you apply heavy business logic.

It is where you preserve evidence.

What Belongs in Bronze?

For an e-commerce project, Bronze tables may include:

bronze.raw_orders_cdc
bronze.raw_order_items_cdc
bronze.raw_payments_api
bronze.raw_customers_crm
bronze.raw_clickstream_events
bronze.raw_inventory_snapshots
bronze.raw_google_ads_spend
bronze.raw_meta_ads_spend

These tables should capture:

• Raw payload
• Source system
• Source file name
• Ingestion timestamp
• Batch ID
• Schema version
• Record hash
• Load status
• Error metadata, if any

Example Bronze table:

CREATE TABLE bronze.raw_payments_api (
    raw_payload STRING,
    source_system STRING,
    source_endpoint STRING,
    ingestion_timestamp TIMESTAMP,
    ingestion_date DATE,
    ingestion_batch_id STRING,
    source_file_name STRING,
    record_hash STRING
);

Bronze Layer Responsibilities

Bronze should handle:

• Data ingestion
• Raw storage
• Source metadata capture
• Schema drift tolerance
• Replay and backfill support
• Auditability
• Source-level troubleshooting

Bronze should usually avoid:

• Complex joins
• Business rules
• Heavy filtering
• Metric calculations
• Dashboard-specific transformations
• Dropping invalid records without traceability

Example: Raw Payment Event

A payment provider may send this JSON:

{
  "payment_id": "pay_9821",
  "order_id": "ORD-771",
  "amount": "129.99",
  "currency": "SGD",
  "status": "succeeded",
  "created_at": "2026-05-16T13:22:10+08:00"
}

In Bronze, the goal is not to decide whether this counts as revenue.

The goal is to store what arrived.

You may later discover that:

• The status mapping was wrong.
• The currency conversion logic changed.
• The order was refunded.
• The payment provider resent the event.
• The timestamp needed normalization.

If the raw event is preserved, you can reprocess the data.

If it was overwritten or cleaned too early, you may lose that ability.

Key Bronze Design Decisions

Before building Bronze, decide:

1. Should Bronze be append-only?

Usually, yes.

Even if a source sends updates or deletes, Bronze should preserve the incoming events.

2. Should Bronze enforce strict schemas?

Not too strictly.

Bronze should tolerate source changes. Strong typing and strict validation usually belong in Silver.

3. Should bad records be dropped?

Usually, no.

Bad records should be stored, tagged, or quarantined.

4. Should analysts query Bronze?

Usually, no.

Bronze is mainly for:

• Data engineers
• Platform teams
• Audit
• Debugging
• Reprocessing

Silver Layer: Build the Trusted Analytical Foundation

Silver is where raw data becomes useful.

This layer applies:

• Cleaning
• Deduplication
• Type casting
• Validation
• Standardization
• Joins
• Identity resolution
• Late-arriving data handling
• Business entity creation

Silver should create reusable, trusted datasets.

It should not be overly dashboard-specific.

What Belongs in Silver?

For the same e-commerce company, Silver tables may include:

silver.orders
silver.order_items
silver.customers
silver.products
silver.payment_transactions
silver.web_sessions
silver.inventory_snapshots
silver.marketing_spend
silver.customer_identity_map

These tables are cleaner than Bronze but still detailed.

They represent business entities or business events.

Example Silver Table: Orders

silver.orders
  order_id
  customer_id
  order_status
  order_created_at_utc
  order_updated_at_utc
  order_channel
  billing_country
  shipping_country
  source_system
  is_deleted
  valid_from
  valid_to

This table has a clear grain:

One row represents one cleaned order record.

Example Silver Table: Payment Transactions

silver.payment_transactions
  payment_id
  order_id
  payment_status
  payment_method
  amount_original
  currency_original
  amount_usd
  fx_rate_used
  payment_created_at_utc
  payment_provider

This table has a different grain:

One row represents one payment transaction or payment attempt.

That distinction matters.

An order may have:

• One successful payment
• Multiple failed payment attempts
• A partial refund
• A chargeback

If the grain is unclear, revenue calculations become unreliable.

Silver Layer Data Quality Rules

Silver is where quality checks become serious.

For silver.orders, you may define rules like:

table: silver.orders

expectations:
  - column: order_id
    rule: not_null

  - column: order_id
    rule: unique_for_current_records

  - column: order_created_at_utc
    rule: not_null

  - column: order_status
    rule: accepted_values
    values:
      - pending
      - paid
      - fulfilled
      - cancelled
      - refunded

  - column: total_amount_usd
    rule: greater_than_or_equal_to
    value: 0

Records that fail validation should not simply disappear.

A better pattern is:

silver.orders_valid
silver.orders_quarantine

The quarantine table should contain:

• Failed record
• Failed rule
• Failure reason
• Source system
• Raw payload
• Pipeline run ID
• Ingestion timestamp

Silver Deduplication Example

Suppose the source sends multiple versions of the same order.

You want only the latest version in Silver.

WITH parsed AS (
    SELECT
        JSON_VALUE(raw_payload, '$.order_id') AS order_id,
        JSON_VALUE(raw_payload, '$.customer_id') AS customer_id,
        JSON_VALUE(raw_payload, '$.status') AS order_status,
        CAST(JSON_VALUE(raw_payload, '$.updated_at') AS TIMESTAMP) AS source_updated_at,
        ingestion_timestamp,
        raw_payload
    FROM bronze.raw_orders_cdc
),

ranked AS (
    SELECT
        *,
        ROW_NUMBER() OVER (
            PARTITION BY order_id
            ORDER BY source_updated_at DESC, ingestion_timestamp DESC
        ) AS rn
    FROM parsed
)

SELECT
    order_id,
    customer_id,
    order_status,
    source_updated_at,
    ingestion_timestamp
FROM ranked
WHERE rn = 1;

In production, this would usually become an incremental merge instead of a full rebuild.

Silver Layer Decision Framework

A table belongs in Silver when:

• It has been parsed and typed.
• It has been cleaned.
• Duplicates have been handled.
• Required fields have been validated.
• It represents a reusable business entity or event.
• It can support multiple downstream use cases.
• It is not designed for only one dashboard.

Examples:

silver.orders
silver.customers
silver.products
silver.payment_transactions
silver.inventory_snapshots

Silver is the reusable foundation of the analytics platform.

If Silver is weak, Gold becomes messy.

If Silver is strong, Gold becomes much easier to build.

Gold Layer: Serve the Business

Gold is where data becomes a product.

Gold tables are built for consumption by:

• Dashboards
• BI tools
• Executives
• Analysts
• Data apps
• Machine learning models
• Reverse ETL workflows
• Operational reporting

Gold is where business logic becomes visible and usable.

What Belongs in Gold?

Gold tables may include:

gold.dim_date
gold.dim_customer
gold.dim_product
gold.dim_region
gold.dim_campaign

gold.fct_order_line
gold.fct_payment
gold.fct_web_session

gold.agg_daily_sales_by_category_region
gold.agg_daily_inventory_position
gold.mart_customer_lifetime_value
gold.mart_marketing_roas
gold.feature_customer_churn_monthly

Gold data is often:

• Aggregated
• Modeled
• Business-defined
• Optimized for performance
• Secured for broader consumption
• Connected to dashboards or semantic layers

Gold Layer and Dimensional Modeling

For reporting and BI, Gold often uses dimensional modeling.

This usually means:

• Fact tables contain measurable business events.
• Dimension tables contain descriptive context.

Example:

gold.fct_order_line
  date_key
  customer_key
  product_key
  campaign_key
  region_key
  order_id
  order_line_id
  quantity
  gross_revenue_usd
  discount_usd
  net_revenue_usd
  tax_usd
  shipping_usd

gold.dim_customer
  customer_key
  global_customer_id
  customer_segment
  acquisition_channel
  country
  first_order_date

gold.dim_product
  product_key
  sku
  product_name
  category
  brand
  launch_date

This structure makes common business questions easier to answer:

• Revenue by product category
• Revenue by country
• Average order value by customer segment
• Repeat purchase rate by acquisition channel
• Refund rate by brand
• Gross margin by region

Gold Aggregate Example

A Gold table for daily sales might look like this:

CREATE TABLE gold.agg_daily_sales_by_category_region AS
SELECT
    d.date,
    p.category,
    r.region_name,
    COUNT(DISTINCT f.order_id) AS orders,
    SUM(f.quantity) AS units_sold,
    SUM(f.gross_revenue_usd) AS gross_revenue_usd,
    SUM(f.discount_usd) AS discount_usd,
    SUM(f.net_revenue_usd) AS net_revenue_usd
FROM gold.fct_order_line f
JOIN gold.dim_date d
    ON f.date_key = d.date_key
JOIN gold.dim_product p
    ON f.product_key = p.product_key
JOIN gold.dim_region r
    ON f.region_key = r.region_key
GROUP BY
    d.date,
    p.category,
    r.region_name;

This table is designed for fast dashboard consumption.

Business users should not need to join raw orders, payments, refunds, products, campaigns, exchange rates, and customer data every time they open a report.

That work should already be done.

Gold Layer Decision Framework

A table belongs in Gold when:

• It supports a specific business use case.
• It has a clear business owner.
• It has a documented grain.
• It contains approved metrics.
• It is safe for the intended audience.
• It is optimized for querying.
• It feeds dashboards, reports, applications, or ML models.

Examples:

gold.finance.daily_revenue
gold.marketing.campaign_roas
gold.customer.customer_lifetime_value
gold.inventory.stockout_risk

A useful rule:

If the table exists because of a source system, it is probably Bronze or Silver. If the table exists because of a business question, it is probably Gold.

The Most Important Design Principle: Define the Grain

Before writing transformations, define the grain.

Grain means:

What does one row represent?

Examples:

silver.orders
One row per current order.

silver.order_items
One row per order line item.

silver.payment_transactions
One row per payment attempt.

silver.inventory_snapshots
One row per SKU, warehouse, and snapshot timestamp.

gold.fct_order_line
One row per completed order line item.

gold.agg_daily_sales_by_category_region
One row per date, category, and region.

Every important table should have this sentence:

One row in this table represents __.

If you cannot write that sentence clearly, the table design is not ready.

Full Implementation Plan for a Real Data Analytics Project

Now let’s walk through how to implement Medallion Architecture in a real project.

Assume the company wants to build analytics for:

• Daily revenue reporting
• Customer lifetime value
• Marketing return on ad spend
• Inventory reporting
• Churn prediction
• Executive KPIs

Step 1: Start With Business Questions

Do not start with tools.

Start with decisions.

Example business questions:

• What was net revenue yesterday?
• Which product categories are growing fastest?
• Which campaigns produce profitable customers?
• Which customers are likely to churn?
• Which warehouses are at risk of stockout?
• What is the refund rate by product?
• What is the difference between gross revenue, net revenue, recognized revenue, and cash collected?

These questions help define:

• Gold tables
• Metrics
• Data quality rules
• Refresh frequency
• Ownership
• Access requirements

Example metric definition:

Metric: Net Revenue

Definition:
Gross order line revenue minus discounts, cancellations, and refunds.

Grain:
Order line.

Currency:
USD.

Time basis:
Order completed date.

Owner:
Finance.

Refresh SLA:
Hourly.

Consumers:
Executive dashboard, finance reporting.

Step 2: Inventory Data Sources

Create a source inventory before building pipelines.

Example:

Source: PostgreSQL orders database
Method: CDC
Latency: 15 minutes
Owner: Commerce engineering
Primary keys: order_id, order_item_id
PII: customer email, shipping address
Expected volume: 3M order lines per month

Source: Payment provider API
Method: REST API extraction
Latency: 30 minutes
Owner: Finance operations
Primary key: payment_id
PII: partial payment metadata
Expected volume: 2M events per month

Source: Website clickstream
Method: Kafka
Latency: near real time
Owner: Growth engineering
Primary key: event_id
PII: anonymous_id, IP-derived location
Expected volume: 200M events per month

This inventory helps decide:

• Ingestion method
• Freshness expectations
• Security controls
• Storage format
• Data retention
• Cost expectations
• Pipeline priority

Step 3: Choose the Platform and Table Format

Medallion Architecture is a logical design pattern.

It can be implemented using different tools.

Common platform choices include:

• Databricks
• Microsoft Fabric
• Snowflake
• BigQuery
• AWS lakehouse services
• Spark-based platforms
• Open-source lakehouse stacks

Common table formats include:

• Delta Lake
• Apache Iceberg
• Apache Hudi

Common transformation tools include:

• Spark
• SQL
• dbt
• Flink
• Databricks Delta Live Tables
• Fabric Data Engineering
• Cloud-native ETL services

Common orchestration tools include:

• Airflow
• Dagster
• Databricks Workflows
• Azure Data Factory
• Fabric Data Factory
• Cloud-native schedulers

The decision should depend on:

• Data volume
• Latency needs
• Team skills
• Existing cloud provider
• Governance requirements
• BI tools
• Machine learning needs
• Streaming requirements
• Cost constraints
• Interoperability needs

Step 4: Design Naming and Storage Standards

A clean naming structure prevents confusion.

Example structure:

bronze.raw_orders_cdc
bronze.raw_payments_api
bronze.raw_clickstream_events

silver.orders
silver.order_items
silver.customers
silver.payment_transactions

gold.finance.daily_revenue
gold.marketing.campaign_roas
gold.customer.customer_lifetime_value

For each table, document:

• Layer
• Domain
• Owner
• Grain
• Refresh frequency
• SLA
• PII classification
• Upstream dependencies
• Downstream consumers

Example metadata:

table: gold.finance.daily_revenue
owner: finance_analytics
layer: gold
domain: finance
grain: one row per date, region, and sales_channel
refresh: hourly
sla: available within 30 minutes
pii: false
upstream:
  - silver.orders
  - silver.order_items
  - silver.refunds

Step 5: Build Bronze Ingestion

Bronze pipelines should optimize for reliability and replayability.

For batch files:

/bronze/orders/ingestion_date=2026-05-17/batch_id=abc123/file.json

For streaming events:

bronze.raw_clickstream_events

For CDC data:

bronze.raw_orders_cdc

A good Bronze pipeline captures:

• Raw record
• Source name
• Source table or endpoint
• File name
• Batch ID
• Ingestion timestamp
• Schema version
• Load status
• Error details

The goal is not to make the data beautiful.

The goal is to make it recoverable.

Step 6: Build Silver Transformations

Silver pipelines should turn raw data into reusable entities.

For orders, Silver processing may include:

• Parse raw payload
• Cast fields
• Standardize timestamps to UTC
• Deduplicate records
• Apply CDC operation logic
• Validate required fields
• Remove or flag test orders
• Quarantine invalid records
• Merge valid records into silver.orders

For payments, Silver processing may include:

• Parse payment events
• Normalize provider statuses
• Convert currencies
• Link payments to orders
• Detect duplicate payment events
• Validate amount and status
• Create silver.payment_transactions

For customers, Silver processing may include:

• Parse CRM and commerce records
• Standardize email and phone fields
• Hash sensitive identifiers
• Resolve customer identities
• Track slowly changing attributes
• Create silver.customers
• Create silver.customer_identity_map

Step 7: Handle Late-Arriving and Changed Data

Real data is messy.

Your architecture must handle:

• Late orders
• Delayed refunds
• Payment retries
• Customer merges
• Campaign attribution changes
• Inventory snapshot failures
• Source schema changes
• Deleted records
• Backfilled historical data

Useful techniques include:

• Source update timestamps
• Ingestion timestamps
• Watermarks
• Incremental merges
• Change data capture
• Slowly changing dimensions
• Quarantine tables
• Reprocessing from Bronze
• Audit columns

Example audit columns:

created_at
updated_at
source_updated_at
ingestion_timestamp
pipeline_run_id
record_hash
is_deleted
valid_from
valid_to

Step 8: Build Gold Data Products

Gold should be shaped around business needs.

Finance Gold tables:

gold.finance.fct_order_line
gold.finance.fct_refund
gold.finance.daily_revenue
gold.finance.monthly_recognized_revenue

Marketing Gold tables:

gold.marketing.fct_campaign_spend
gold.marketing.fct_attributed_order
gold.marketing.daily_roas
gold.marketing.customer_acquisition_cost

Customer Gold tables:

gold.customer.dim_customer
gold.customer.customer_360
gold.customer.lifetime_value
gold.customer.churn_features

Inventory Gold tables:

gold.inventory.daily_stock_position
gold.inventory.stockout_risk
gold.inventory.inventory_turnover

Each Gold table should have:

• Clear owner
• Clear consumer
• Clear metric definitions
• Clear grain
• Clear refresh SLA
• Clear access policy

Step 9: Add Orchestration

A real platform needs orchestration.

Example dependency chain:

bronze.raw_orders_cdc
  ↓
silver.orders
  ↓
gold.fct_order_line
  ↓
gold.daily_revenue
  ↓
Executive dashboard

The orchestrator should manage:

• Scheduling
• Dependencies
• Retries
• Alerts
• Run history
• Failure handling
• Backfills
• SLA monitoring

A failed Bronze ingestion should alert engineering.

A failed Gold revenue table should alert both engineering and analytics owners.

Step 10: Add Lineage and Cataloging

Lineage helps answer:

• Where did this number come from?
• Which source tables feed this dashboard?
• What changed upstream?
• Which downstream reports are affected?
• Which pipeline failed?
• Which data quality check broke?

At minimum, the catalog should include:

• Table name
• Description
• Owner
• Layer
• Grain
• Domain
• Source systems
• Upstream dependencies
• Downstream consumers
• Freshness
• Quality status
• PII classification
• Access policy
• Metric definitions

Without lineage, debugging becomes detective work.

With lineage, debugging becomes engineering.

Step 11: Secure Each Layer Differently

Not every layer should have the same access.

Bronze often contains raw sensitive data.

Silver may contain cleaned but still sensitive business data.

Gold should expose only what users need.

Example access model:

LayerAccessPII RiskMain UseBronzeData engineering, platform, auditHighReplay, debugging, auditSilverEngineering, analytics engineering, selected analystsMediumClean reusable dataGoldBusiness users, BI tools, approved appsLow to mediumReporting and decisions

Security design should include:

• Row-level security
• Column masking
• PII classification
• Role-based access control
• Audit logging
• Retention policies
• Data minimization

Do not wait until after dashboards are built to think about governance.

Complete Example: Daily Revenue Dashboard

Let’s follow one business question end to end.

The business asks:

What was net revenue yesterday by country and product category?

Bronze Sources

Raw data lands in:

bronze.raw_orders_cdc
bronze.raw_order_items_cdc
bronze.raw_refunds_api
bronze.raw_products_erp
bronze.raw_fx_rates

At this stage:

• No revenue calculation
• No business aggregation
• No dashboard logic
• Raw records preserved

Silver Entities

Cleaned data is produced:

silver.orders
silver.order_items
silver.refunds
silver.products
silver.fx_rates

Silver handles:

• Deduplication
• Timestamp normalization
• Currency conversion
• Refund matching
• Product validation
• Test order removal
• Status standardization

Gold Data Product

Business-ready tables are produced:

gold.dim_date
gold.dim_product
gold.dim_country
gold.fct_order_line
gold.fct_refund
gold.daily_net_revenue

Gold calculation example:

CREATE TABLE gold.daily_net_revenue AS
SELECT
    d.date,
    c.country_name,
    p.category,
    SUM(f.net_revenue_usd) - COALESCE(SUM(r.refund_amount_usd), 0) AS net_revenue_usd
FROM gold.fct_order_line f
JOIN gold.dim_date d
    ON f.date_key = d.date_key
JOIN gold.dim_product p
    ON f.product_key = p.product_key
JOIN gold.dim_country c
    ON f.country_key = c.country_key
LEFT JOIN gold.fct_refund r
    ON f.order_line_id = r.order_line_id
GROUP BY
    d.date,
    c.country_name,
    p.category;

The dashboard reads from:

gold.daily_net_revenue

This gives business users one trusted place to answer the question.

Data Quality Gates by Layer

Quality should become stricter as data moves upward.

Bronze Quality Checks

Bronze checks focus on ingestion.

Examples:

• Did the file arrive?
• Can the payload be read?
• Was the record stored?
• Was metadata captured?
• Is the source schema recorded?
• Is the record count within expected range?

Bronze should preserve data, even if it is messy.

Silver Quality Checks

Silver checks focus on correctness.

Examples:

• Primary keys are not null.
• Current records are unique.
• Required fields are populated.
• Timestamps are valid.
• Currency codes are valid.
• Amounts are non-negative where required.
• Foreign keys resolve.
• Duplicate events are handled.
• Late-arriving data is processed.

Silver should make data trustworthy.

Gold Quality Checks

Gold checks focus on business trust.

Examples:

• Revenue reconciles with finance-approved logic.
• Dashboard totals match expected controls.
• Aggregates are not double-counted.
• Metrics are documented.
• Refresh SLA is met.
• Row-level security works.
• Sensitive fields are not exposed.

Gold should make data usable.

Common Anti-Patterns

1. Treating Bronze as a Random Dumping Ground

Bronze should be raw, but not careless.

Bad Bronze tables often miss:

• Ingestion timestamp
• Source name
• Batch ID
• File name
• Schema version
• Load status

Without metadata, raw data becomes hard to debug.

2. Letting Analysts Query Bronze Directly

This creates duplicated cleaning logic and inconsistent reporting.

Bronze is for preservation and replay.

Gold is for consumption.

3. Making Silver Too Dashboard-Specific

This is a warning sign:

silver.orders_for_finance_dashboard_final_v3

Silver should be reusable.

Dashboard-specific logic belongs in Gold.

4. Turning Gold Into a Copy of Silver

Gold should not simply rename Silver tables.

Gold should represent:

• Metrics
• Dimensions
• Aggregates
• Business logic
• Analytical products

5. Dropping Bad Records Without Traceability

Bad records are inevitable.

Do not silently delete them.

Use quarantine tables.

6. Hiding Business Logic in BI Tools

If revenue logic exists only inside a dashboard formula, it will eventually fork.

Core business logic should live in governed transformations or a governed semantic layer.

7. Building Everything as Full Refresh

Full rebuilds are simple at small scale.

At larger scale, they become expensive and slow.

Use incremental processing where appropriate.

8. No Metric Ownership

Every important Gold metric should have:

• Business owner
• Technical owner
• Definition
• Grain
• Refresh SLA
• Known limitations

Without ownership, trust decays.

Production Readiness Checklist

Before calling a Medallion Architecture project production-ready, check the following.

Architecture

• Bronze, Silver, and Gold responsibilities are documented.
• Each table has a layer.
• Each table has an owner.
• Each table has a defined grain.
• Naming conventions are consistent.
• Source-to-dashboard lineage exists.

Data Engineering

• Bronze ingestion is replayable.
• Silver transformations are tested.
• CDC logic is handled.
• Deletes are handled.
• Late-arriving data is handled.
• Backfill strategy exists.
• Quarantine tables exist.

Data Quality

• Quality checks exist per layer.
• Critical checks can block promotion.
• Non-critical checks create alerts.
• Failed records are observable.
• Freshness is monitored.

Governance

• PII is classified.
• Access differs by layer.
• Gold tables expose only necessary fields.
• Metric definitions are documented.
• Table ownership is assigned.

Operations

• Pipelines are orchestrated.
• Failures trigger alerts.
• SLAs are defined.
• Costs are monitored.
• Schema drift is detected.
• Run history is retained.

Consumption

• Dashboards use Gold tables.
• Analysts know which tables are certified.
• Business users understand metric definitions.
• ML users know which features are production-ready.

When Not to Use Full Medallion Architecture

Medallion Architecture is powerful, but not every project needs the full pattern.

You may not need it when:

• The project is temporary.
• Data volume is very small.
• There is only one source.
• There is only one report.
• Historical reprocessing is not needed.
• The work is early-stage exploration.

A simple table, view, or dbt model may be enough.

But once you have:

• Multiple sources
• Multiple teams
• Changing business logic
• Data quality issues
• Compliance needs
• Reprocessing requirements
• Executive reporting

Medallion Architecture becomes extremely valuable.

Final Takeaway

Medallion Architecture is not really about Bronze, Silver, and Gold. It is about responsibility.

• Bronze protects the raw evidence.
• Silver creates trusted analytical records.
• Gold delivers business-ready data products.

That separation gives analytics teams something every growing company eventually needs:

The ability to move fast without losing trust.

• When a dashboard number changes, you can trace it.
• When a source system breaks, you can isolate it.
• When a business rule changes, you can reprocess it.
• When someone asks where a metric came from, you can explain it.

A good Medallion Architecture does not just produce tables. It produces confidence.