Medallion architecture and where it fits in modern data environments

As data platforms grow in scale and complexity, teams need ways to structure data that support reliability, incremental processing, and governance without slowing delivery. One pattern that has gained wide adoption is Medallion architecture: a layered approach to data refinement that makes data quality, lineage, and intent explicit.

This article explains what Medallion architecture is, why it exists, how it is typically implemented, and where it fits within modern data environments.

What is Medallion architecture?

Medallion architecture is a layered data refinement pattern. Each layer represents a defined level of data quality, transformation, and readiness for use.

It is commonly described using three primary layers:

Bronze layer: raw or minimally processed data ingested from source systems.
Silver layer: cleaned, standardised, and conformed data suitable for general analytical use.
Gold layer: curated, business-aligned datasets optimised for reporting, analytics, or machine learning.

Each layer has a clear contract: what the data represents, how reliable it is, and how it should be used. Some organisations introduce additional layers or rename them, but the underlying principle remains the same: data is refined incrementally as it moves closer to consumption.

Why Medallion architecture exists

Modern data automation platforms ingest data from many systems, each with its own schema, semantics, and quality characteristics. Without an explicit structuring pattern, teams commonly encounter unclear data quality, opaque lineage, and operational fragility as pipelines grow.

Medallion architecture addresses these issues by separating concerns. Raw ingestion, standardisation, and consumption-ready modelling are treated as distinct stages, each with its own responsibilities and guarantees.

Core characteristics of Medallion architecture

A well-implemented Medallion architecture typically exhibits:

Explicit refinement stages: data moves through clearly defined layers rather than ad hoc staging tables.
Incremental processing: each layer processes only new or changed data, rather than reprocessing full history.
Traceable lineage: transformations between layers are documented and auditable.
Consumption awareness: upper layers are designed around known access patterns rather than generic storage.
Controlled schema evolution: changes in upstream sources are absorbed in lower layers without immediately breaking downstream consumers.

These characteristics make the architecture resilient as data volumes, teams, and use cases grow.

Implementing Medallion architecture in a modern data environment

Medallion architecture is not tied to a specific technology stack. It can be implemented in warehouses, lakehouses, or hybrid environments. What matters is the discipline applied to each layer.

Bronze: raw ingestion

The bronze layer focuses on fidelity, not usability.

Typical characteristics include:

Ingestion principle	Description	Why it matters	Architectural benefit	Practical indicators
Minimal transformation	Source data is ingested with only essential technical adjustments	Preserves original meaning; avoids premature business logic	Enables safe reprocessing and alternative interpretations	Ingestion logic limited to type normalisation and basic parsing
Source fidelity	Original structure, values, and semantics are retained	Ensures traceability and auditability	Supports regulatory review and historical reconstruction	Raw tables closely resemble source schemas
Ingestion metadata	Load-time, source system, and context metadata is captured with each record	Enables operational monitoring and forensic analysis	Improves observability and recovery from failures	Presence of ingestion timestamps, batch IDs, and source identifiers
Reprocessability	Downstream layers can be rebuilt from raw data without re-extracting sources	Decouples ingestion from transformation; reduces source system load	Safer evolution of business logic and data models	Ability to backfill or replay transformations independently

The bronze layer acts as a durable record of what was received, when, and from where.

Silver: cleansing and standardisation

The silver layer introduces structure and consistency.

Common responsibilities include:

Principle	Description	Why it matters	Architectural benefit	Practical indicators
Consistent types & naming	Apply uniform data types and naming conventions across datasets	Reduces confusion and errors in downstream processing	Simplifies joins, transformations, and integration	Field names and types are standardised across related tables
Deduplication & basic quality	Remove duplicate records and enforce basic data quality rules	Prevents inflated metrics or inconsistent analyses	Improves trust in intermediate datasets	Duplicate rows removed; nulls, invalid values, and constraints handled
Conformed datasets	Align related datasets to shared keys, reference tables, or domain models	Enables consistent joins and cross-dataset analysis	Simplifies downstream aggregation and analytics	Dimension tables or key-mapping consistently applied
Incremental refresh	Process only new or changed data instead of full reloads	Reduces processing time and resource usage	Scales pipelines linearly with data changes	Watermarks or CDC streams are implemented for incremental processing
Version-controlled transformations	Store transformation logic in version control	Enables reproducibility and safe evolution	Supports auditability and rollback capabilities	SQL scripts or transformation code tracked in Git or equivalent system

This layer is where raw data becomes broadly usable across teams.

Gold: curated, consumption-ready datasets

The gold layer is explicitly consumer-oriented.

It typically includes:

Principle	Description	Why it matters	Architectural benefit	Practical indicators
Business logic & derived metrics	Apply aggregations, calculations, and business rules	Produces datasets that are directly usable for reporting or analytics	Reduces repetitive transformations at consumption layer	Gold tables contain precomputed KPIs, metrics, or summaries
Consumption-aligned schemas	Design schemas based on reporting, analytical, or ML access patterns	Improves query efficiency and usability	Optimised for downstream workloads	Schema reflects BI or analytics dimensional needs
Performance optimisation	Partitioning, clustering, or caching aligned with known access patterns	Minimises latency and resource usage for end-users	Efficient query execution and predictable performance	Data layout matches common queries or ML feature retrieval
Metadata & governance documentation	Include lineage, annotations, and governance details	Ensures datasets can be audited and reused safely	Improves transparency, compliance, and collaboration	Lineage captured; business definitions, owners, and transformations documented

Gold datasets are not generic; they exist to serve known analytical or operational use cases.

Orchestration and observability

Across all layers, successful implementations rely on:

Clear dependency management between layers
Monitoring of freshness, volume, and data drift
Idempotent pipelines that support safe reprocessing
Alerting on failures and unexpected behaviour

Without operational discipline, Medallion layers quickly become naming conventions rather than architectural guarantees.

How Medallion architecture relates to other patterns

Medallion architecture does not replace other modelling or optimisation techniques. Instead, it provides a structural backbone that complements them. For example:

Materialised or pre-computed datasets often sit within the silver or gold layers to improve performance.
Dimensional modelling is commonly applied in silver or gold layers to support analytical querying.
Semantic or metrics layers typically sit above gold, defining business meaning rather than physical structure.

Medallion architecture defines where transformations belong; other patterns define how data is shaped and consumed.

Common pitfalls

Teams adopting Medallion architecture often struggle when:

Layers are treated as storage locations rather than refinement stages
Transformations are pushed too early into bronze
Lineage and metadata are neglected
Incremental processing quietly degrades into full reloads

The pattern only delivers value when layers are intentionally designed and enforced.

Closing thoughts

Medallion architecture is not a product feature or a storage strategy. It is a data platform pattern that makes data refinement explicit, repeatable, and governable.

Its value lies in clarity: clarity of data quality, of transformation responsibility, and of lineage. In modern data environments, it works best when combined with disciplined orchestration, incremental processing, and clearly defined consumption layers.

Where Bragi fits in this pattern

Medallion architecture introduces structural complexity: multiple layers, incremental transformations, and dependencies coordinated and governed over time.

Bragi operates at this operational layer. It does not define what bronze, silver, or gold mean. Instead, it helps teams run the pattern consistently by tracking lineage across refinement stages, coordinating incremental loads and dependencies, and making transformation behaviour explicit and observable.

Learn more about Bragi and how it supports Medallion architecture in modern data environments by getting in touch with our team.

See Bragi in action

Learn more about Bragi in a personalised demo

Speak directly to Bragi’s co-founders, not a sales agent, and explore how Bragi can transform your data workflows.