Bronze, silver and gold are useful names for three different responsibilities in an analytics platform.
They are not a requirement to create three copies of every table.
The medallion pattern is valuable because it separates source fidelity, data quality and business meaning. That separation makes data pipelines easier to replay, test and govern.
But smaller analytics teams sometimes copy the terminology without the underlying need. They build a raw table, a cleaned table and a mart even when each layer contains almost identical SQL.
That creates more pipelines, more storage and more objects without improving trust.
The right question is:
Which boundaries do we need so that source changes, data-quality work and business logic can evolve independently?
Actiknow’s data engineering and business intelligence work uses layered architectures when the boundaries solve real operational problems, not because every warehouse needs exactly three named tiers.
The Short Answer
Use a full bronze/silver/gold pattern when:
- Many sources feed shared business models.
- Raw replay is important.
- Data quality/conformance is substantial.
- Several downstream products reuse cleaned data.
- Multiple engineering teams work on the platform.
- Data science and BI share curated layers.
- Auditability matters.
Use a simpler raw + mart pattern when:
- The estate is small.
- Transformations are straightforward.
- Few consumers reuse intermediate models.
- Business rules are stable.
- A third layer would mostly duplicate SQL.
The principle is separation of responsibilities, not the number three.
What Is Medallion Architecture?
Medallion architecture organizes data through progressively more curated layers.
Common names:
- Bronze: raw/source-aligned.
- Silver: cleaned/conformed.
- Gold: business-ready.
The concept is strongly associated with lakehouse platforms but applies equally well to cloud warehouses.
A Snowflake implementation might call the layers:
- RAW.
- STAGING/CORE.
- MART.
The names matter less than the contracts between them.
Bronze: Preserve Source Fidelity
The bronze layer should answer:
What did the source system give us?
Typical characteristics:
- Minimal transformation.
- Source-oriented names.
- Ingestion metadata.
- Load timestamp.
- Source identifier.
- Raw payload where useful.
- Deleted/change metadata.
- Historical replay support.
Bronze is useful for debugging.
When a dashboard number is disputed, engineers can trace back to source-aligned data rather than reverse-engineering a transformed mart.
Bronze Is Not Necessarily “Dirty Forever”
Raw does not mean unmanaged.
You still need:
- Access control.
- Retention.
- Schema monitoring.
- Encryption.
- PII classification.
- Load observability.
The difference is that bronze minimizes business interpretation.
Do not silently “fix” source values in the raw layer.
Why Bronze Helps With Replay
Suppose transformation logic was wrong for three months.
If raw historical data is retained, you can correct the logic and rebuild downstream tables.
Without raw retention, you may need to:
- Re-extract from source.
- Hope the source still retains history.
- Reconstruct data from backups.
Bronze creates a recovery boundary.
But not every dataset needs indefinite raw history.
Set retention by value and risk.
Silver: Make Data Reusable
Silver should answer:
What is the clean, reliable representation of this domain?
Typical work includes:
- Type standardization.
- Deduplication.
- Null handling.
- Code normalization.
- Schema conformance.
- Business keys.
- Reference-data joins.
- CDC resolution.
- Basic data-quality controls.
- Cross-source identity where appropriate.
Silver is where source-specific mess begins to become reusable enterprise data.
Silver Should Not Become a Second Raw Layer
A common anti-pattern:
- RAW.CUSTOMER
- STG.CUSTOMER
- SILVER.CUSTOMER
with each model doing almost nothing.
Every layer should have a purpose.
If staging exists only as a technical intermediate for one transformation, it does not necessarily need to become a long-lived architectural tier.
Gold: Make Data Business-Ready
Gold should answer:
What should analysts and BI tools use?
Typical gold objects:
- Fact sales.
- Fact orders.
- Fact membership.
- Dim customer.
- Dim product.
- Finance mart.
- Marketing performance mart.
- Executive KPI mart.
Gold contains deliberate business semantics.
It should be:
- Documented.
- Tested.
- Governed.
- Stable enough for downstream consumption.
Power BI/Tableau should usually consume gold or semantic models built over gold, not raw ingestion tables.
Gold Is Not the Same as a Dashboard
Gold is the data product.
The BI semantic layer can add:
- Measures.
- Hierarchies.
- Formatting.
- RLS.
- Relationships.
- Calculation groups.
- User-friendly naming.
Keep core reusable business logic as close to the governed data layer as practical, while BI-specific calculations can remain in the semantic model.
Why Three Layers Became Popular
The pattern creates useful separation:
- Source changes affect bronze ingestion.
- Cleaning/conformance evolves in silver.
- Business reporting evolves in gold.
This improves:
- Testing.
- Ownership.
- Lineage.
- Reuse.
- Backfills.
- Debugging.
For a large estate, those boundaries are valuable.
When Three Layers Become Ceremony
Consider:
- One source table.
- Ten columns.
- Simple rename.
- One dashboard.
Pipeline:
Bronze → Silver → Gold → Semantic Model
may be unnecessary.
If silver and gold each add only aliases, the layers create operational overhead.
A simpler pattern may be:
Raw → Business Mart → Semantic Model.
Good architecture minimizes accidental complexity.
Layer by Transformation Responsibility
Ask what changes at each boundary.
- Raw: Preserve source.
- Conformed: Make data technically trustworthy and reusable.
- Business: Apply domain meaning.
If two responsibilities can safely live together for a small dataset, combine them.
Do Not Layer by Tool
Avoid:
- Fivetran layer.
- dbt layer.
- Snowflake layer.
- Power BI layer.
Those are technologies, not data responsibilities.
A layer should have a semantic purpose.
Medallion in Snowflake
A practical Snowflake structure might be:
- RAW database/schema: Connector-owned source tables.
- DEV/PROD transformation databases: Staging/conformed models.
- MART schemas: Business facts/dimensions.
- Semantic layer: Power BI/Tableau/Omni.
Snowflake does not require medallion naming.
Use database/schema boundaries that support:
- Permissions.
- Environment separation.
- Ownership.
- Cost.
- Deployment.
Medallion in Microsoft Fabric
Fabric lakehouse guidance often uses medallion terminology naturally.
A typical pattern:
- Bronze: Raw Delta data in OneLake.
- Silver: Validated/conformed Delta tables.
- Gold: Analytics-ready tables consumed by Power BI, potentially through Direct Lake.
Fabric’s integrated lakehouse and Power BI architecture makes the gold layer especially important because it can become the direct semantic-model source.
But the same warning applies:
Do not create layers with no transformation purpose.
Medallion in BigQuery
BigQuery teams may use datasets such as:
- raw.
- staging.
- core.
- mart.
The underlying principle is identical.
Because storage is relatively easy to create, teams can overproduce materialized tables.
Choose views versus tables based on:
- Reuse.
- Performance.
- Cost.
- Freshness.
- Transformation complexity.
Not every layer must physically duplicate data.
Physical vs Logical Layers
A layer can be:
- A physical table.
- A view.
- An incremental model.
- A materialized view.
- A semantic model.
The architecture diagram does not require every arrow to represent another full copy.
For lightweight conformance, a view may be enough.
For expensive reused transformations, a materialized table may be justified.
Raw Layer Ownership
Prefer ingestion tooling to own raw/source-aligned schemas.
Avoid analysts manually editing raw tables.
Capture metadata such as:
- Loaded at.
- Source file/batch.
- Connector sync timestamp.
- Deleted flag.
- Source update timestamp.
These fields make reconciliation and debugging easier.
Silver Layer Ownership
Silver should usually be owned by data engineering/analytics engineering.
It should enforce technical contracts.
Examples:
- One row per customer.
- Valid currency code.
- Normalized timestamps.
- Unique order ID.
- Resolved latest CDC state.
Tests should align to these contracts.
Gold Layer Ownership
Gold requires business ownership as well as technical ownership.
For example:
- Finance owns recognized revenue definition.
- Sales owns qualified pipeline definition.
- Membership owns active-member definition.
Engineering implements.
The business approves.
This is where data governance becomes practical.
Avoid Hiding Business Logic in Bronze
A raw connector table should not decide:
- What is an active customer?
- Which opportunity stages count?
- How revenue is recognized?
Those definitions will change.
Keep raw replayable.
Apply business semantics downstream.
Avoid Source Logic in Gold
Gold should not be full of source-specific quirks such as:
- Salesforce status code 7.
- ERP table X123.
- API boolean flag Y.
Silver/conformed layers should translate those details into reusable concepts.
Gold should speak business language.
Data Quality by Layer
Bronze checks:
- Did data arrive?
- Expected volume?
- Schema changed?
- Load completed?
Silver checks:
- Keys unique?
- Types valid?
- References resolve?
- Duplicates removed?
- Required fields populated?
Gold checks:
- Metrics reconcile?
- Business rules valid?
- Dimensions complete?
- Financial totals match?
- KPI thresholds plausible?
This layered quality model makes incidents easier to localize.
Freshness by Layer
Track freshness end to end.
- Source freshness.
- Bronze freshness.
- Silver freshness.
- Gold freshness.
- Semantic-model freshness.
- Dashboard freshness.
An executive does not care that bronze loaded at 9:00 if gold failed at 8:00.
Define SLAs at the consumption layer.
Backfills Are Easier With Clear Layers
A safe backfill can:
- Reload bronze/source history.
- Rebuild affected silver partitions.
- Recompute gold.
- Validate.
- Refresh semantic models.
Clear dependencies reduce accidental partial corrections.
Lineage should show which downstream objects are affected.
Storage Cost Is Usually Not the Main Problem
Cloud storage can be cheap.
The bigger cost of unnecessary layers is:
- Compute.
- Pipeline runtime.
- Testing.
- Deployment.
- Monitoring.
- Developer cognition.
Ten unnecessary models are ten more objects someone must understand.
Optimize for maintainability.
Do You Need a Silver Layer?
Ask:
- Do several marts reuse cleaned data?
- Are there complex dedupe rules?
- Do multiple sources represent the same entity?
- Are source schemas unstable?
- Is conformance substantial?
If yes, silver is valuable.
If no, raw → gold may be enough.
Do You Need a Bronze Layer?
Ask:
- Can the source be replayed reliably?
- Does connector raw data already exist?
- Do you need audit/debug history?
- Will source APIs retain historical data?
- Are transformations reversible?
If a managed connector already lands a source-aligned raw schema, that may already be your bronze layer.
Do not create “bronze2.”
Do You Need a Gold Layer?
For BI, usually yes in concept.
You need a governed business-ready interface.
But it might be:
- Warehouse marts.
- Views.
- Semantic model.
- Metric layer.
The form depends on the estate.
What matters is that executive reporting does not directly depend on volatile source structures.
A Two-Layer Pattern for Smaller Teams
Pattern:
RAW→ MART
RAW: Source-aligned ingestion.
MART: Cleaned + business-ready dimensional models.
Use when:
- Few sources.
- Simple rules.
- Limited reuse.
- Small team.
Add a conformed/core layer later when duplication appears.
A Three-Layer Pattern for Growing Teams
Pattern:
RAW→ CORE→ MART
CORE: Reusable cleaned entities.
Use when:
- Customer logic is reused.
- Product hierarchy is shared.
- Multiple marts need common facts.
- Several source systems overlap.
This is often the sweet spot for mature BI.
A Four-Layer Pattern Is Sometimes Justified
Some enterprises use:
- Raw.
- Staging.
- Core/conformed.
- Mart.
That can work when staging handles technical transformation and core represents durable domain models.
But every layer should have an explicit contract.
If nobody can explain the difference between staging and core, merge them.
Naming Conventions
Choose names users understand.
Examples:
- RAW.
- CORE.
- MART.
or:
- BRONZE.
- SILVER.
- GOLD.
Do not mix terminology randomly.
Document:
- Purpose.
- Allowed transformations.
- Owner.
- Retention.
- Who can consume.
- Materialization.
- Testing requirements.
Access Control by Layer
Raw often contains sensitive source data.
Limit access.
Silver may still contain detailed PII.
Gold should expose only what consumers need.
Use layer boundaries to reduce unnecessary data exposure.
The executive dashboard should not require broad raw-schema access.
Development and Production
Do not confuse medallion layers with environments.
You may have:
- DEV_RAW / DEV_CORE / DEV_MART.
- PROD_RAW / PROD_CORE / PROD_MART.
Or other environment strategies.
Bronze is not “development.”
Gold is not “production.”
They are data refinement stages.
How to Know Your Architecture Is Over-Layered
Warning signs:
- Every model is SELECT *.
- Tables have one consumer.
- Developers cannot explain layer differences.
- Backfills take hours because of redundant materialization.
- The same business logic appears in several layers.
- Storage/object count grows faster than data value.
- A small schema has hundreds of models.
Simplify.
How to Know You Need Another Layer
Warning signs:
- Every mart repeats the same cleaning logic.
- Source quirks leak into dashboards.
- Different teams dedupe customers differently.
- Backfills are risky.
- Raw schemas change frequently.
- Business marts depend directly on connector tables.
Add a reusable conformance boundary.
A Practical Design Workshop
For each major dataset, write:
- Source representation.
- Raw retention need.
- Cleaning/conformance rules.
- Reusable domain model.
- Business marts.
- Consumers.
- SLA.
- Owner.
- Tests.
Then draw the minimum layers needed.
Do not start by drawing three boxes.
Frequently Asked Questions
What are bronze, silver and gold layers?
Bronze is source-aligned/raw data, silver is cleaned and conformed reusable data, and gold is business-ready data for analytics and BI.
Is medallion architecture only for Databricks?
No. The pattern can be implemented in lakehouses or cloud warehouses such as Snowflake, BigQuery and Microsoft Fabric.
Does every dataset need all three layers?
No. Small or simple datasets may need only raw and business-ready layers.
Should Power BI connect to bronze data?
Generally not for governed enterprise reporting. Power BI should consume curated business-ready data or a governed semantic model.
Is staging the same as silver?
Sometimes, but not always. Staging may be a temporary technical transformation layer, while silver/core usually represents reusable cleaned data.
Do medallion layers need separate physical tables?
No. Depending on workload, a layer can use views, tables, incremental models or other materializations.
Does medallion architecture improve data quality automatically?
No. It creates places to enforce quality controls. The team still needs to define and implement the tests.
Sources and Further Reading
Conclusion
Medallion architecture is valuable because it separates responsibilities.
Not because bronze, silver and gold are magic words.
- Preserve source fidelity.
- Create reusable trusted data where needed.
- Publish stable business-ready models.
For a complex platform, three or more layers may be justified.
For a smaller BI estate, raw plus mart may be cleaner.
Start with the boundaries your team needs.
Add layers only when they reduce duplication, risk or coupling.
If you are redesigning a Snowflake, BigQuery or Fabric analytics estate, Actiknow can help define a layered architecture that supports reconciliation and BI without unnecessary pipeline ceremony. Discuss your BI data architecture with Actiknow.