Medallion architecture is a data design pattern that organizes a lakehouse into three layers of increasing quality: bronze for raw data exactly as it arrived, silver for data that has been cleansed and conformed, and gold for business-ready tables built for reporting and analytics. Each layer is a contract with the next, so a report reading gold never needs to know what the raw source looked like.
The name follows the medal order. Databricks popularized the pattern for Delta Lake, but it now describes a way of working on any lakehouse platform, including Snowflake and Oracle Autonomous Data Warehouse. It is a convention about where each kind of work happens, not a product or a file format.
The Three Layers: Bronze, Silver and Gold
Each layer answers a different question about the data, and each has a different audience.
| Layer | What it holds | Who works in it |
|---|---|---|
| Bronze | Raw extracts exactly as the source delivered them, append-only, with load timestamps and source details | Data engineers replaying or auditing a load |
| Silver | Deduplicated, typed and validated records, with keys conformed across source systems | Analysts and data scientists building new models |
| Gold | Aggregated tables and metrics with business names, shaped for a specific subject | Finance, operations and BI tools |
Bronze is deliberately left untouched. If a transformation downstream turns out to be wrong, the raw history is still there to rebuild from, and that safety net is the main reason the layer exists.
How Data Moves Through the Layers
- Land the extract in bronze. Data arrives from source systems by batch file, API or change data capture and is stored as-is, tagged with when and where it came from.
- Cleanse and conform into silver. Duplicates are removed, data types enforced, invalid values handled, and codes from different systems mapped to shared keys.
- Model and aggregate into gold. Silver tables are joined and summarized into subject tables, such as revenue by period, product and business unit.
- Serve gold to consumers. Dashboards, finance reports, machine learning features and AI assistants read from gold rather than from anything upstream.
- Reprocess when rules change. Because bronze keeps the full history, a corrected rule can be replayed through silver and gold without asking the source system for the data again.
Gold is where most business users meet the data. On the consumption side, Orbit Analytics provides Fusion Analytics with governed, analytics-ready data models over Oracle Fusion Cloud, which is the role a gold layer plays for finance teams.
Why Lakehouse Teams Layer Their Data
- Traceability: every gold figure can be walked back through silver to the raw record that produced it, which supports audit and debugging.
- Separation of concerns: ingestion, quality and business logic live in different layers, so a change to one does not break the others.
- Reprocessing without re-extraction: source systems are queried once, and history is rebuilt from bronze when needed.
- Controlled access: raw data carrying sensitive fields can stay restricted in bronze while curated gold tables are shared widely.
- Incremental loads: each layer processes only new or changed records, so compute grows with the volume of change rather than the total volume of data.
Data Quality Rules at Each Layer
Quality checks tighten as data moves up. Bronze checks are structural: did the file arrive, is the row count plausible, and does the schema match what was expected.
Silver is where validation does the real work. It tests ranges, referential integrity and duplicates, and it quarantines records that fail rather than silently dropping them, so the failures can be investigated and replayed.
Gold checks are business checks. A typical example is confirming that general ledger balances in a gold table still reconcile to the source trial balance for the same period and ledger.
Medallion Architecture for Oracle Fusion and EBS Data
Oracle ERP data suits the pattern because the raw source is hard to use directly. Fusion Cloud exposes data through BI Cloud Connector (BICC) extracts, BI Publisher and REST APIs, while EBS stores it across thousands of normalized tables with terse column names and flexfields whose meaning lives in configuration.
- Bronze: BICC or EBS table extracts land unchanged, including every flexfield segment and the last-update timestamps that drive incremental loads.
- Silver: records are conformed so that a ledger, supplier or item means the same thing whether it came from Fusion or EBS, and descriptive flexfields are decoded into named columns.
- Gold: finance subject tables such as GL balances by period, payables aging and order-to-cash, named in the language the finance team already uses.
Orbit Analytics feeds this pattern with a data pipeline that extracts Oracle Fusion and EBS data incrementally and delivers it into Snowflake, Databricks, Redshift or Oracle ADW, with 200+ pre-built connectors for the non-Oracle sources that usually sit alongside the ERP.
Common Mistakes in Medallion Designs
Most problems with the pattern come from doing a piece of work in the wrong layer, or from treating the layers as folders rather than contracts.
- Cleaning data on arrival: transforming records as they land in bronze destroys the raw copy the layer exists to preserve.
- Adding layers for every team: extra tiers and team-specific copies recreate the sprawl the pattern was meant to prevent.
- Business logic in silver: calculations such as gross margin or days sales outstanding belong in gold, where they can be named and governed once.
- One gold table per dashboard: building gold around screens multiplies definitions of the same metric. Gold should be organized around business subjects.
- No owner for each layer: every layer needs a named owner for its quality rules, or failures pass silently upward into reports.
Medallion Architecture vs. a Traditional Data Warehouse
The medallion pattern did not invent layering. Classic warehouses have long used a staging area, an integration layer and presentation data marts, and the data lake added cheap storage for raw files of any shape. What differs is where the layers live and what they keep.
A traditional warehouse usually transforms data before loading it (ETL) and often discards staging data once it has been integrated. A medallion lakehouse loads first and transforms inside the platform (ELT), keeps raw history permanently in bronze, and holds structured and semi-structured data in the same store.
Gold plays the part of the presentation layer or data mart, so for a report user the two designs look much the same. The difference is felt by the engineers who have to rebuild a table, audit a figure or add a new source.
Frequently Asked Questions
Q1. What is medallion architecture in simple terms?
It is a way of organizing a lakehouse into three layers: raw data in bronze, cleaned data in silver and business-ready data in gold. Each layer improves on the one before it, and reports read only from the top.
Q2. What is the difference between the silver and gold layers?
Silver holds clean, conformed records at roughly the same detail as the source. Gold holds tables modeled and aggregated for a specific business subject, with named metrics that reporting tools use directly.
Q3. Is medallion architecture only for Databricks?
No. Databricks popularized the name, but the pattern works on any platform that can store raw and transformed data side by side, including Snowflake, Redshift and Oracle ADW.
Q4. Do you always need all three layers?
Most teams keep all three because each does a separate job. Small or simple sources sometimes skip a physical silver table, but the cleansing still has to happen somewhere before data reaches gold.
Q5. Can Oracle ERP data follow the medallion pattern?
Yes. Fusion and EBS extracts land raw in bronze, are decoded and conformed in silver, and become finance subject tables in gold, which suits ERP data well because its raw form is hard to read.
Getting Oracle ERP data into bronze reliably, and out of gold in a shape finance trusts, is where most of the effort in a lakehouse sits. Orbit Analytics covers both ends for Oracle Fusion Cloud and EBS. Request a demo to see it running on your own data platform.
