What is medallion architecture (bronze/silver/gold) in a data lakehouse?

Medallion architecture is a data organization pattern that structures a data lakehouse into three progressive layers: bronze (raw ingestion), silver (cleaned and validated), and gold (business-ready aggregates). Each layer refines the data further, so downstream consumers always work with data that matches their quality and context requirements. The sections below walk through each layer in detail, compare the pattern to traditional warehousing, and cover when and how to implement it.

How does medallion architecture actually organize data?

Medallion architecture organizes data into three sequential layers, bronze, silver, and gold, where each layer represents a higher degree of data quality and transformation. Raw data lands in bronze, gets cleaned and standardized in silver, and is aggregated into business-ready datasets in gold. Data flows forward through the layers, but nothing from earlier ones gets deleted.

Each layer serves a distinct audience. Bronze is for engineers who need the original record. Silver is for analysts who need clean, reliable data. Gold is for business users and applications that need precomputed, domain-specific views. Because earlier layers are preserved, any transformation can be replayed or audited at any point, which makes the entire pipeline traceable and reproducible.

This layered approach also decouples ingestion from transformation. You can land new data sources quickly into bronze without worrying about downstream quality requirements, then apply transformations progressively as the data moves toward gold. Teams working on different layers can operate independently without blocking each other.

What types of data belong in the bronze layer?

The bronze layer holds raw, unmodified data exactly as it arrived from the source system, whether database change events, API responses, log files, sensor readings, flat files, or streaming records. No schema enforcement, deduplication, or filtering is applied at this stage. The goal is fidelity: bronze is a complete historical record of everything that entered the pipeline.

In practice, bronze tables often store data in its original format, whether JSON, Avro, CSV, or Parquet, sometimes with a small set of metadata columns added on ingestion: a timestamp indicating when the record arrived, the source system identifier, and a unique ingestion ID. These additions don’t alter the payload itself but make it easier to trace records downstream.

Because bronze data is never overwritten, it acts as an insurance policy. If a transformation in silver turns out to be wrong, you can reprocess from bronze without going back to the source system. This matters especially when source systems have limited retention windows or when regulatory requirements demand a full audit trail of what was received and when.

What transformations happen between bronze and silver?

The bronze-to-silver step focuses on data quality: deduplication, null handling, type casting, schema normalization, and basic validation rules. Records that fail validation are typically quarantined rather than dropped, so the failure stays visible and can be investigated. The result is a dataset that is consistent, typed, and trustworthy, even if it’s not yet aggregated or domain-specific.

Concretely, this means converting string timestamps to proper datetime types, splitting concatenated fields, resolving encoding issues, and applying agreed-upon naming conventions across sources. If data arrives from multiple systems that represent the same entity differently, the silver layer is where those representations get unified into a canonical form.

Silver is also where joins across sources often happen for the first time. A customer record from a CRM and an order record from an ERP can be linked at this stage, producing an enriched dataset that neither source system holds on its own. The silver layer doesn’t pre-aggregate this data, it simply makes it clean, joined, and ready for whatever analytical workload comes next.

What makes the gold layer different from silver?

The gold layer contains pre-aggregated, business-domain-specific datasets built for dashboards, reports, machine learning models, and APIs. While silver holds clean, normalized records at roughly source granularity, gold holds purpose-built views: daily revenue by product line, customer lifetime value scores, inventory turnover ratios. Gold tables are shaped around how the business actually asks questions.

That distinction matters because silver data, though clean, is still technical in structure. A business analyst querying silver would need to know join keys, understand grain, and write complex SQL. Gold removes that burden by precomputing the most common aggregations and presenting data in terms the business already uses, such as „weekly active users“ rather than raw event counts.

Gold datasets are also often denormalized intentionally. Normalization is a virtue in silver because it reduces redundancy and keeps the data flexible. In gold, some redundancy is acceptable if it makes queries faster and simpler. A wide, flat table that a BI tool can query without joins is often the right choice at this layer, even if a database architect would wince at it anywhere else.

How does medallion architecture differ from a traditional data warehouse?

A traditional data warehouse enforces a fixed schema at load time, meaning data must conform to a defined structure before it can enter the system. Medallion architecture inverts this: raw data lands in bronze immediately, and schema enforcement happens progressively in later layers. This schema-on-read approach makes it far easier to onboard new data sources without upfront modeling work.

Traditional warehouses also tend to discard or overwrite source data once it has been transformed. In a lakehouse architecture, bronze data is retained indefinitely, giving teams the ability to reprocess historical data when business logic changes. That’s a meaningful operational difference when requirements evolve or when a transformation error needs to be corrected after the fact.

The trade-off is that medallion architecture requires more deliberate pipeline management. In a traditional warehouse, the ETL process handles quality enforcement before data enters the system. With medallion layers, quality is distributed across the pipeline, which means teams need clear ownership of each layer and well-defined contracts about what silver and gold tables guarantee. Neither approach is inherently superior, and the right choice depends on how dynamic your data sources are and how frequently your analytical requirements change.

When should you add more than three medallion layers?

Adding more than three layers makes sense when a single transformation step between bronze and silver, or silver and gold, becomes too large or too mixed in purpose to manage cleanly. A common extension is a „platinum“ layer for highly curated, externally shared datasets, or an intermediate „silver plus“ layer for domain-specific cleaning that sits between general normalization and full aggregation.

The signal that you need an additional layer is usually one of two things: either a single transformation job is doing too many conceptually different things at once, or different teams need to consume data at a granularity that doesn’t fit neatly into silver or gold as currently defined. In those cases, introducing a named intermediate layer makes the pipeline easier to reason about and maintain.

That said, adding layers has a real cost. Each additional layer means more pipeline jobs to maintain, more storage, and more places where something can go wrong. Before adding a fourth layer, it’s worth asking whether the existing three could be restructured, or whether the problem is really one of unclear ownership rather than missing architecture. More layers aren’t always better, they’re only better when they solve a real problem in the current design.

What tools are commonly used to implement medallion architecture?

Medallion architecture is a pattern, not a product, so it can be implemented with a wide range of tools. The most common combination in 2026 involves an open table format such as Apache Iceberg for managing the lakehouse storage layer, a distributed processing engine such as Apache Spark™ for running transformations between layers, and an orchestration tool such as Apache Airflow for scheduling and monitoring pipeline runs.

For the query and serving layer, Trino is a widely used option because it can query data across multiple storage systems without moving it, which fits naturally with the multi-layer structure of medallion pipelines. Streaming ingestion into bronze often relies on Apache Kafka®, which provides a durable, replayable log of events that maps well onto the bronze layer’s requirement for complete, unmodified records.

Storage itself typically lives on object storage, whether on-premises or a cloud provider’s equivalent, with the open table format managing metadata, versioning, and schema evolution on top. This keeps the architecture cloud-agnostic and avoids tying the pipeline to any single vendor’s proprietary format. Working reference demos that show how these components fit together in practice are often more useful than reading about the pattern in the abstract.

How Stackable helps with medallion architecture

The Stackable Data Platform (SDP) is a modular, Kubernetes-native platform that provides the open-source components needed to build and operate a medallion architecture pipeline without proprietary lock-in. Concretely, the SDP includes:

Managed Apache Kafka® for bronze ingestion: The Stackable Operator for Apache Kafka® handles deployment, configuration, and lifecycle management of Kafka clusters on Kubernetes, giving you a durable, replayable ingestion layer out of the box.
Apache Spark™ for inter-layer transformations: The SDP includes a Spark operator that runs distributed transformation jobs for bronze-to-silver and silver-to-gold processing, with full support for Apache Iceberg as the underlying table format.
Trino for cross-layer querying: Trino runs natively on the SDP and can query bronze, silver, and gold layers simultaneously, which is useful during development and for ad hoc investigation of pipeline issues.
Infrastructure as code throughout: Every component is configured declaratively, so your entire medallion pipeline, from ingestion to serving, is versioned, reproducible, and auditable.
Data sovereignty by design: The SDP runs on-premises, in any cloud, or in hybrid environments, so your data stays where your compliance requirements say it must.

If you want to see how these components work together in a real lakehouse setup, the SDP demos include end-to-end examples. To discuss your specific architecture requirements, get in touch with the Stackable team directly.