Bronze, silver, and gold are the names given to the three layers inside a medallion-style data architecture, each one describing a different state of trustworthiness and readiness that data passes through on its way from a source system to something a business user can actually rely on. Bronze holds data close to how it arrived, largely unedited. Silver holds that same data after it has been cleaned, deduplicated, and standardized into a consistent shape. Gold holds data that has been aggregated and modeled into the specific form a report, dashboard, or business question actually needs. The names are a metaphor for value increasing at each stage, not a technical requirement.
The layers exist because different people need different things from the same underlying data, and cramming all of it into one undifferentiated table forces everyone to solve the same cleaning and modeling problems over and over. An analyst wants a clean, aggregated number ready to drop into a report. A data scientist might want the messier, granular version to build features from. A compliance team might need the original, completely unedited record to prove what actually happened. Splitting data by layer means each of those needs gets served by a purpose built table instead of everyone fighting over one table that was never quite right for anybody.
The naive version of this idea is renaming a folder "gold" and calling it done, without actually enforcing what has to be true for data to earn that label. A real gold table has gone through validated business logic, reconciled against known totals where that matters, and is stable enough that a report built on it will not silently change meaning next week. A folder that is called gold purely by convention, with no validation behind the promotion, gives people false confidence that a table is more trustworthy than it actually is, which is arguably worse than an honest raw table that nobody was fooled about.
By 2026, the bronze, silver, gold naming has spread well beyond the platform ecosystem that popularized it and is now used loosely across data engineering teams regardless of what specific tools they run underneath. It shows up in dbt project folder structures, in orchestration tool documentation, and in the way data teams describe their own pipelines out loud, even at companies that never adopted a full lakehouse platform. Not every team uses the exact three names, some prefer raw, staged, and curated, but the underlying three tier idea of progressive trust has become close to a shared vocabulary across the field.
This page covers what specifically belongs in each of the three layers, how this naming compares to the generic raw, trusted, and curated zone naming used outside the Databricks ecosystem, how the layers differ from ELT pipeline stages, and where a three layer split earns its complexity versus where it does not. The idea worth keeping is that each layer answers a different question about the same data, is this what actually happened, is this clean and consistent, and is this ready for the specific decision someone is about to make, and mixing those questions up inside one table is where a lot of data trust problems quietly start.
Bronze captures data close to the form it arrived in, usually append-only, keeping every record including ones that might later turn out to be duplicates, malformed, or otherwise unusable. Schema here tends to be loose or absent entirely, since enforcing a strict structure at this stage risks rejecting data that might still be useful once someone figures out what to do with its quirks. Retention is usually long, sometimes indefinite, since the whole value of this layer is having an unedited copy to fall back on, and data engineering teams almost always own it exclusively.
Silver takes that raw material and applies the unglamorous but essential work: deduplicating records, casting fields to consistent types, standardizing formats like dates and currencies, and joining data across sources that need to be combined to mean anything useful. The schema here is enforced and consistent, but the data is still usually granular, row level detail rather than summary numbers, which makes this the layer data scientists and analysts building their own custom analysis often work from directly rather than waiting for a gold table that may not exist yet for their specific question.
Gold takes the cleaned, standardized data from silver and applies business logic on top of it, aggregating, filtering, and denormalizing it into the specific shape a report or dashboard actually needs. Revenue by region and month, active customers per week, whatever the business actually asks about repeatedly, lives here in a form built for a known question rather than for flexibility. This layer usually has the smallest number of tables, the most documentation, and joint ownership between data engineering and the business or analytics team that actually relies on the numbers.
Between every hop, well built pipelines run validation checks rather than moving data forward on faith, testing that a transformation did not silently drop rows, introduce unexpected nulls, or break a known reconciliation total. These checks typically get stricter the higher a table climbs, since a broken assumption in bronze is annoying but recoverable, while a broken assumption that reaches gold undetected can end up directly inside a report someone presents to leadership as fact.
Long before bronze, silver, and gold became common vocabulary, plenty of data platforms used a similar three zone structure with more literal names: a raw or landing zone for data close to source, a trusted or conformed zone for cleaned and validated data, and a curated or consumption zone for data shaped for specific business use. Cloud vendor architecture guides and enterprise data platforms built on this pattern for years under these more descriptive, less metaphorical names.
Functionally, the two naming schemes are doing nearly the same job, though the boundaries drawn are not always identical. A "trusted" zone name puts the emphasis on validation, is this data verified as correct, while "silver" carries a slightly softer implication of general cleanliness that does not always require the same rigor. In practice, teams define the actual criteria for each zone or layer themselves, so the difference in emphasis matters less than whatever specific rules a given team actually enforces.
The honest tradeoff is mostly about communication rather than technical substance. Bronze, silver, gold has become recognizable enough across the industry by 2026 that a new hire coming from another company will likely understand it instantly, while "trusted zone" or "conformed layer" varies enough between organizations that the same new hire might need it explained. That recognizability is a real, if modest, advantage, especially for onboarding and for talking to vendors or consultants who default to the popular naming.
In practice, the choice of naming rarely matters as much as people spend time arguing about it. What actually determines whether a data platform is trustworthy is the discipline behind each layer, the validation rules, the ownership, the testing, not which metaphor was chosen to label it. A team with a rigorously enforced raw, trusted, curated structure is in better shape than a team with bronze, silver, gold folders that nobody actually validates on the way up.
An ELT pipeline is described in terms of steps a job actually performs: extract data from a source, load it into a landing area, then run one or more transform steps that clean, join, and reshape it. These are actions in a defined order, usually laid out as a directed graph of tasks that an orchestration tool executes on a schedule, and the vocabulary is about what the pipeline does at each moment.
Bronze, silver, and gold describe something different: not the actions a pipeline takes, but the states data sits in once it lands somewhere queryable. A layer is a noun, a destination, a table someone can actually query and trust to a known degree. A transform stage is closer to a verb, a step that happens in the process of getting data from one state to another, and a single transform stage can sometimes move data across what would be considered two layer boundaries at once, or a pipeline can have several transform stages that never produce anything meant to be queried directly by a person.
This gets confusing in casual conversation because people call a specific dbt model or transformation job "the silver transform," blending the job with the destination it produces. That is usually fine as shorthand, but it hides a real distinction worth keeping straight when designing a pipeline: the layer is what you are promising about the data once it lands, and the stage is simply the mechanism used to get it there, which can be redesigned, split, or combined without necessarily changing what the destination layer is supposed to guarantee.
Keeping the two ideas separate matters because they solve different problems. Deciding on layers is a data modeling and governance question, what trust levels does this organization need to distinguish. Designing stages is a pipeline engineering question, what is the most efficient and reliable way to actually produce that outcome. A team that only thinks in stages can end up with a pipeline that runs fine but has no coherent layer strategy behind it, tables scattered at inconsistent trust levels with no clear naming or promise attached to any of them.
The three way split earns its complexity when there are genuinely different audiences pulling on the same underlying data. A machine learning team wanting granular, near-raw signal to build features, an analyst wanting clean row-level data for a custom cut nobody has built a report for yet, and an executive wanting a single trusted number for a board deck are three genuinely different needs, and serving all three from one table usually means the table is either too messy for the executive or too summarized for the ML team.
It also fits well in regulated or audit sensitive environments, where being able to prove that a number in a report traces back cleanly to an untouched, unedited original record actually matters. Keeping bronze completely separate and immutable from anything derived downstream gives a clean lineage story: here is exactly what arrived, here is exactly what we did to it, and here is the final number, each step traceable and none of them silently overwriting what came before.
It fits poorly for a pipeline with one known output feeding one consumer, where maintaining three separate materialized layers, each with its own storage, its own tests, its own scheduling, is real overhead for a problem that a single well tested transformation would solve just as reliably. Layering adds the most value when there are competing needs to reconcile. If there is only one need, the reconciliation the layers exist to provide is not actually happening, and the structure is just extra surface area to maintain.
It also fits poorly for short lived, exploratory work, a prototype dashboard someone is building to test an idea, or a one-off analysis answering a question that will not be asked again. Building formal bronze, silver, and gold tables for something that will be deleted or forgotten within a month burns effort on governance that the object of the governance will not live long enough to need. The split earns itself over the lifetime of a table, and some tables simply do not have much lifetime to earn it over.
Write the actual promotion criteria down for each layer, specific enough that two different engineers building two different pipelines would make the same call about where a given transformation belongs. Vague guidance like "silver is cleaned data" leaves too much room for one team's silver to look like another team's gold, which quietly breaks the shared vocabulary the layering was supposed to provide across the organization in the first place.
Keep bronze complete and untouched, resisting the urge to filter out records that look obviously wrong at ingestion time. What looks like garbage today can turn out to be exactly the record someone needs six months from now to understand why a downstream number looked strange on a specific date, and once a record is filtered out of bronze, it is usually gone for good rather than just hidden somewhere recoverable.
Keep silver granular and general purpose rather than baking in logic that only serves one specific report. The moment silver starts encoding business rules meant for a single dashboard, it stops being a reusable foundation other teams can build their own gold tables from, and starts being a shadow gold table with an inconsistent name. Save the business specific shaping for gold, and keep silver focused purely on correctness and consistency.
Keep the number of gold tables limited and document the business logic behind each one thoroughly, since gold is where two teams are most likely to build the same metric slightly differently and end up disagreeing in a meeting. A short, well documented list of gold tables that everyone trusts beats a sprawling one where nobody is quite sure which "revenue" table is the official one anymore.
Set ownership and access deliberately per layer rather than applying one blanket policy everywhere. Bronze, often containing raw and possibly sensitive data, usually warrants tighter access restricted to data engineering. Gold, validated and meant for broad consumption, usually warrants the widest access. Matching access to trust level is part of what makes the layering useful, rather than just a naming convention with no real consequence attached to it.
They are the three commonly used names for a layered data structure, where bronze holds data close to its raw form, silver holds cleaned and standardized data, and gold holds data aggregated and shaped for specific business use.
Bronze holds data close to how it arrived from its source, usually with minimal transformation, loose or no schema enforcement, and long or indefinite retention, so there is always an unedited copy available if something needs to be reprocessed.
Silver is cleaned, deduplicated, and standardized but still generally granular and reusable across many purposes. Gold is aggregated and shaped around specific business questions, with far fewer tables and far more documentation behind each one.
Functionally, yes, in most cases. They are different naming conventions for a similar layered idea. Bronze, silver, gold has become more widely recognized by 2026, but the specific rules a team enforces matter more than which naming it uses.
No. A layer describes a destination and a trust guarantee about data at rest. A transform stage describes a processing step in a pipeline's execution, and a single stage can sometimes span what would be considered more than one layer boundary.
No. The split earns its overhead when multiple audiences need different versions of the same data. Single-purpose pipelines with one consumer, or short-lived exploratory work, often do not benefit enough to justify maintaining three separate layers.
Data engineering usually owns bronze and much of silver, since that work is largely technical. Gold is often owned jointly with the business or analytics team that relies on it, since the logic there reflects specific business definitions rather than pure data cleaning.
Keeping an untouched bronze copy means a mistake found later in the cleaning logic can be fixed by reprocessing from the original data, rather than being stuck with whatever silver already produced and no way to verify what was lost or changed.
