A productive lakehouse separates the data cycle into three layers: Bronze preserves the original data, Silver validates and standardizes it, and Gold turns it into information ready for decision-making, BI, and AI.. The value lies not in using three colors, but in establishing traceability, quality rules, responsible parties, and controls that allow data to be reused without reconstructing it for each project.
Microsoft and Databricks document this approach as medallion architecture, Databricks considers it a recommended practice, not a mandatory requirement for any lakehouse.
At MAIA by Scanda We take it a step further: architecture should reduce conflicting versions of the same figure, increase the sources integrated into the catalog, and shorten the time between receiving a data and making a decision. These are business metrics; counting tables is not one of them.
Taxonomic definitions
1. Bronze layer
It is the area of Ingestion and preservation of the source data. It maintains the information with the fewest possible business modifications: files, events, operational tables, APIs, ERP, CRM, IoT or transactional systems.
Its main objective is to maintain traceability and allow the subsequent layers to be reconstructed without having to consult each source system again.
Databricks recommends persisting this layer precisely so that you can regenerate the subsequent layers when necessary.
2. Silver layer
It is the layer where the data stops being only available and begins to be reliable and reusable.
Here processes such as:
- quality validation;
- normalization of formats;
- deletion or treatment of duplicates;
- homologation of identifiers;
- integration between sources;
- application of reusable business rules;
- quarantine of invalid records;
- Enrichment and formation of entities.
Microsoft describes Silver as the stage where errors are fixed, formats are standardized, and duplicates are eliminated; Databricks positions it as the refined foundation for analysts and data scientists.
3. Gold layer
It is the layer of governed consumption. It contains data products prepared for a specific decision, process, or use case: semantic models, executive KPIs, analytical datasets, aggregations, reporting, forecasting, or controlled inputs for AI applications.
Gold should not simply be «Silver with fewer columns». It should express the language of the business: customer, sales, margin, inventory, production, risk, profitability, or level of service.
Microsoft proposes Gold as the curated layer for reporting and visualization, while the latest reference architectures already consider its consumption from Copilot, data agents, and other AI experiences as well.
Comparative table
| Variable | Bronze | Silver | Gold |
| Purpose | Preserve the source data | Make it reliable and reusable | Convert it into a data product |
| State of the data | Raw / source-aligned | Validated, clean, standardized | Curated and business-oriented |
| Transformations | Minimals | Quality, joins, MDM, rules, deduplication | KPIs, aggregations, semantic models |
| Primary consumer | Data engineering, auditing | Engineering, analytics, data science | BI, business, applications and AI |
| Granularity | Máxima | Detailed and consistent | Adapted to the use case |
| Access | Very restricted | Restricted by role | According to product and audience |
| Critical rule | Do not lose traceability | Do not accept data without verified quality | Do not publish metrics without ownership and definition |
| Typical error | Change the original data | Doubling business rules | Creating a different «truth» through dashboards |
| Financial risk | Re-investigations, re-processing, loss of evidence | Manual reconciliation and rework | Decisions based on inconsistent figures |
| Executive metric | Completeness and freshness | Quality and reuse | Time from the data to the decision |
The medallion architecture seeks precisely to increase the structure and quality as the data progresses from Bronze to Silver and subsequently to Gold.
Technical team
What role does each layer play in a production-ready lakehouse?
A common mistake is to interpret Bronze, Silver and Gold as three folders.
They are not.
They are three different quality contracts.
In a productive environment, each transition must answer four questions:
- What condition must the data meet to enter?
- What transformations are allowed?
- Who is responsible for its quality?
- Which consumers can use it?
Without those rules, you have layer storage, but not architecture.
1. Design Gold products first, not Bronze pipelines
It may seem contradictory, but the design should start by asking:
What decision does the business need to make?
Then we work backwards.
For example, if Financial Management needs a consolidated view of margin per unit:
Gold
Margin per product, unit, customer and period.
↓
Silver
Approved customers + master products + sales + returns + cost-based calculations.
↓
Bronze
ERP 1 + ERP 2 + CRM + business files + product catalog.
This logic avoids one of the most expensive problems of a data platform: ingesting hundreds of sources before knowing what they will be used for.
At MAIA by Scanda, our range of Data Intelligence Part of the job is precisely to integrate, govern, and provide quality to information from multiple sources to turn it into reliable decisions, not to accumulate data without a business question behind it.
2. Building Bronze as a reconstructable record of reality
Bronze should allow you to answer:
«What do we really receive from the source system?»
Minimum requirements
- To preserve the original data or a faithful representation of it.
- Record the date and time of ingestion.
- Identify the source system.
- Register batch, file, or source event.
- Maintain traceability of scheme changes.
- Define retention policy.
- Detecting duplicate charges.
- Separating technical errors from business transformations.
- Restricting the direct access of end users.
Microsoft recommends that you keep the data in Bronze in its original format or use formats such as Parquet or Delta, depending on the scenario.
Why is it financially important?
Because without a reliable raw layer, fixing a rule in Silver can force:
- re-check source systems;
- reconstructing historical archives;
- repeat extractions;
- request information from other areas;
- reconcile the figures again;
- stop dashboards or models.
That turns a logical error of hours into a reprocessing of days.
Bronze protects the cost of reconstruction.
3. Convert Silver into a truly reusable source
Silver is usually the layer that determines whether a platform scales or ends up full of duplicate pipelines.
Its function is to produce consistent entities that different consumers can reuse.
Examples:
- customer_conformed
- product_master
- transaccion_validada
- ordered_integrated
- inventory_normalized
- active_industrial
- event_operational
What must happen in Silver
- Apply quality rules.
- Homologize units and formats.
- Resolve identities.
- Duplicate.
- Standardize keys.
- Integrating sources.
- Managing missing data.
- Apply MDM when appropriate.
- Create history when the business needs it.
- Classifying or protecting sensitive information.
- Separate rejected records.
The best practices of Databricks recommend applying this layer Schema enforcement and explicit quality controls, Instead of allowing any data to continue automatically towards consumption.
The expensive mistake: turning the same thing five times
If Finance, Operations, Sales, and Data Science build four different versions of «active customer,» the cost is not just in the computing.
The point is that there are now four truths.
The first metric that should concern a CIO is not how many terabytes the lakehouse has, but:
How many versions of the same figure exist within the organization?
This is also one of the diagnostic metrics we use in MAIA by Scanda to assess the maturity of the data.
4. Building Gold around decisions, not around systems
Bronze can be organized by source system.
Silver can be organized by entities.
Gold should be organized by business result.
Suitable examples:
- profitability per customer;
- forecast store × SKU;
- OEE per line;
- risk from the supplier;
- availability per operation;
- customer lifetime value;
- rotation and inventory coverage;
- financial consolidation.
Examples that are not very useful:
- SAP_gold
- CRM_gold
- ERP_gold
That still describes technology, not business.
Microsoft exemplifies Gold with structures such as daily sales, customer lifetime value, and inventory for forecasting.
Gold does not have to be a single physical layer
Depending on the platform, it can be implemented as:
- Delta tables;
- a lakehouse;
- a warehouse;
- materialized views;
- semantic models;
- data products by domain.
In Microsoft Fabric, for example, there are patterns for both a layer-by-layer lakehouse and a lakehouse with Bronze and Silver, and a Gold lakehouse served from a warehouse.
That's why Bronze, Silver and Gold describe logical responsibilities before specific products..
How to design a Bronze-Silver-Gold lakehouse step by step
Step 1. Define the consumption cases
Before creating infrastructure, document:
- a decision that wants to be enabled;
- user who will consume the data;
- required frequency;
- granularity;
- historical period;
- level of freshness;
- sensitive data involved;
- Related business KPI.
A lakehouse without a defined consumer usually becomes technically correct storage and is financially difficult to justify.
Step 2. Map the sources against the data product
For each Gold product, the following information must be identified:
- source systems;
- owner of each source;
- update frequency;
- volume;
- scheme;
- historical quality;
- available keys;
- access policies;
- dependents.
The goal is not to consume everything.
It is ingesting what supports a decision.
Step 3. Establish Bronze → Silver contracts
A load should advance only when it exceeds defined controls.
Examples of controls
- complete received file;
- Mandatory columns present;
- valid format;
- dates within a range;
- valid primary keys;
- acceptable percentage of nulls;
- duplicates within the agreed threshold;
- sensitive data correctly classified;
- Volume consistent with its expected behavior.
Invalid records should not disappear silently.
They must Reject, quarantine, or remedy with traceability.
Step 4. Establish Silver → Gold contracts
Before publishing information for business, the following should be met at least:
- reconciliation against the source;
- formal definition of the KPI;
- business owner;
- approved quality controls;
- security model;
- expected level of freshness;
- traceability available;
- performance test;
- change policy.
Gold must be certifiable, Not only consultable.
Step 5. Separate security by layer
Not everyone needs to go into all the layers.
A reasonable pattern is:
Bronze: Engineering and data operation.
Silver: Authorized engineering, analytics and data science.
Gold: Business consumers and applications by function.
Microsoft documents patterns where permissions are separated by workspace, artifact, table, row, and column, and recommends treating governance, identity, RBAC, and lineage as cross-functional capabilities throughout the data lifecycle.
This is especially important when the lakehouse starts to feed agents or AI applications.
The model does not correct poorly designed permissions: consume what is given access to.
Step 6. Separate development, testing, and production
An enterprise lakehouse should not be directly modified in production.
The cycle needs:
- version control;
- revision of changes;
- quality tests;
- Dev/Test/Prod environments;
- variables by environment;
- deploying gates;
- rollback;
- Approval authorities.
Microsoft Fabric, for example, supports integration with Git and deployment pipelines between development, testing, and production.
What matters is not the specific tool.
The «rapid change in production» is to be eliminated as an operational process.
What controls do productive lakehouses need?
A lakehouse really enters production when it can respond not only What data it contains, But not what is happening to them.
Controls by dominance
Ingestion
- Freshness.
- Latency.
- Expected volume vs. received volume.
- Judgments by source.
- Duplication of burdens.
- Schematic changes.
Quality
- Completeness.
- Validity.
- Uniqueness.
- Consistency.
- Referential integrity.
- Accuracy when there is a source of reconciliation.
Operation
- Pipeline time.
- Reattempts.
- Backlog.
- Cost of computing.
- Growth in storage.
- Incidents related to data product.
Government
- Technical Owner.
- Business owner.
- Lineage.
- Classification.
- RBAC.
- Retention.
- Evidence of changes.
Consumption
- Active users.
- Consultations.
- Effective freshness.
- Response time.
- Products without consumption.
- Duplicate KPIs.
The materialized views of Fabric, for example, already incorporate capabilities for dependencies, quality rules, refresh, and lineage visualization from Bronze to Silver and Gold.
How to measure whether Bronze, Silver and Gold are generating value
At MAIA by Scanda, we believe that a data architecture should not be reported to the executive committee with «number of pipelines» or «number of tables.».
For us, three questions are much more useful:
1. How many versions of the same figure exist?
If Comercial says 8.2 million and Finance says 7.9 million, there still isn't a reliable source of decision.
2. What percentage of critical sources is included in the master catalog?
It allows you to measure whether the foundation actually covers the business or only a fraction of it.
3. How long does it take for a data to become a decision?
A correct figure that comes after the decision window has closed has little operational value.
These metrics are part of the data and AI dashboard defined by MAIA by Scanda.
How to translate architecture into ROI, EBITDA and risk
Bronze, Silver and Gold do not generate ROI from using those names.
The value appears when you eliminate costs or enable a result.
Lever 1. Reduce operating cost
It can be measured with:
Current data cost =
hours of manual integration
- Reconciliation
- correction of errors
- Reprocessing
- maintenance of duplicate pipelines
- incidents
- infrastructure.
A governed architecture seeks to reduce those expenses.
When these reductions affect operating expenses, they can translate into an impact on EBITDA.
Lever 2. Reduce decision time
Example:
Current report available: 10th day of the month.
Objective report: Day 2.
The financial question is not «do we save eight days?».
It is:
What decision could not be made before due to those eight days of delay?
This could be:
- inventory;
- forecast;
- production;
- pricing;
- shopping;
- collection;
- availability;
- risk.
The benefit is calculated based on that decision, not on the dashboard.
Lever 3. Avoid the cost of reprofiling
Bronze allows reconstruction.
Silver allows for reuse.
Gold avoids recreating logic for the consumer.
Overall, this reduces the marginal cost of enabling a new use case.
A platform that demands reconstruction of input, cleaning, and rules every time a new AI model appears is not a scalable platform: it is a collection of projects.
Executive formula
A simple way to evaluate the project over 12 months is:
ROI = (Annual economic benefit − Annual TCO) / Annual TCO × 100
Where the TCO should include:
- platform;
- storage;
- computation;
- engineering;
- government;
- operation;
- observability;
- support;
- evolution;
- Data management.
And the benefit must be built with data from the operation itself, Not with a generic benchmark. That is also the methodology we use at MAIA by Scanda to structure business cases and Proofs of Value.
Errors that increase the TCO of a lakehouse
Error 1. Transform Bronze into something unrecognizable
If Bronze already includes commercial rules, the possibility of rebuilding and auditing from the original source is lost.
Error 2. Allowing BI to consume Bronze directly
The result is usually that each dashboard implements its own cleaning and its own definition of the data.
Error 3. Converting Silver into a second data lake without governance
Silver should consolidate logical reusable. If everything works and nothing is certified, only the place of the problem has changed.
Error 4. Building Gold by application
Gold should reflect data products or decisions, not the structure of the source systems.
Error 5. Not assigning owners
Every critical metric needs a technical and a business manager.
Error 6. Measuring activity instead of reliability
«We process 20 TB» does not demonstrate value.
«Reducing the number of financial indicator versions from four to one» does indeed demonstrate an operational change.
Predictive conclusion
During the next adoption cycles, Gold will no longer be just a dashboard layer.
Our forecast at MAIA by Scanda is that it will gradually become the An interface governed by corporate data and three simultaneous consumers: people, analytical models, and AI agents.
Current reference architectures already show Gold products being consumed not only from BI, but also from Copilot and data agents.
That will raise the standard.
It will no longer be enough to ask:
«Does the dashboard have the correct number?»
We will also have to answer:
- What origin gave rise to that number?;
- What rules transformed him?;
- Who authorized its use?;
- Which agent can consume it?;
- Which version is currently in effect?;
- Can it be reproduced?;
- What happens if they change their source?
Therefore, the Bronze-Silver-Gold architecture will remain useful, but the real differentiator will not be having three layers.
It will be governing them as a chain of trust.
CTA final of MAIA
Turn your lakehouse into a platform for decision-making and AI, not another repository
At MAIA by Scanda We start with a simple question: What decision does your company need to improve and what data does it need to trust it with?
From there we evaluate sources, quality, integration, governance, and architecture to determine what should remain in Bronze, what needs to be resolved in Silver, and what data products should move to Gold.
If today you have data distributed across ERP, CRM, files, cloud platforms, or operating systems, and there are still different versions of the same figure, let's talk. We can help you define a data architecture that is results-oriented and prepared for analytics and AI in production.
FAQ
1. Is it mandatory to have three separate lakehouses for Bronze, Silver, and Gold?
No. Bronze, Silver, and Gold are primarily logical layers. They can be implemented through schemas within a single lakehouse or through separate lakehouses and warehouses. The decision depends on scale, security, equipment, and governance needs. At Fabric, Microsoft even recommends separating layers into separate workspaces when greater control is needed.
2. Should AI models consume only Gold data?
Not necessarily. Data scientists can work with Silver data when they need greater granularity, while production AI products should consume governed datasets that are suited to their use case. Databricks identifies Silver as a useful layer for data science and Gold as an optimized layer for consumers and business products.
3. How do I know if a lakehouse is ready for production?
It must have reproducible ingestion, automatic quality controls, lineage, owners, role-based security, monitoring, development/test/production environments, and Gold products with verifiable business definitions. If an error cannot be traced from the KPI to its source, the platform still has a production gap.
Español 
English