Build Medallion Layers for Analysts, Not Just Engineers
Bronze, silver, and gold are useful labels because they describe increasing levels of refinement. They become less useful when a team designs the layers only around pipeline convenience. A medallion architecture succeeds when the gold layer is genuinely easier for analysts to understand, trust, and reuse than the raw and enriched data underneath it.
Microsoft recommends medallion architecture for Fabric and OneLake, so the pattern is relevant to DP-600. For a Fabric Analytics Engineer Associate, however, remembering the bronze-silver-gold sequence is the easy part. The harder work is deciding what each layer promises, who should consume it, and how business meaning becomes progressively more stable.
The best design starts from the questions analysts must answer and works backward to the data engineering controls needed to support those answers.
Bronze should preserve evidence, not convenience
The bronze layer is valuable because it preserves the data close to the way it arrived. That gives engineers a replay point when transformation logic changes, a reference for investigating source anomalies, and a place to compare what the source delivered with what later layers produced.
This is where data lake thinking matters. Raw data may include structured tables, files, events, or external data exposed through shortcuts. The goal is not to make bronze pleasant for analysts. It is to retain enough source fidelity that the team can rebuild or explain downstream results.
Changing names, coercing values, or deleting records too early can remove evidence. Bronze should be governed, but it should not pretend to be a reporting model.
Silver is where reliability becomes reusable
Silver is more than “cleaned data.” It is the layer where engineers standardize keys, deduplicate records, enforce types, handle late or malformed data, and create consistent entities that can be reused by multiple analytical products.
The quality rules should be explicit. What makes a customer record valid? How are duplicate orders identified? What happens when an exchange rate is missing? Which timestamps are authoritative? Those decisions determine whether later analysis can be trusted.
That makes data quality a structural concern rather than a final check. A silver table should have known expectations for completeness, uniqueness, validity, timeliness, and reconciliation.
Gold should reflect how analysts ask questions
Gold is where many medallion implementations either become useful or become another engineering layer with nicer names. The design should reflect business grain, dimensions, measures, and common analytical paths rather than merely exposing transformed source tables.
For reporting, that often means facts and dimensions organized so filters behave predictably and business definitions have one home. A star-schema design is frequently a better analytical contract than a set of normalized operational entities because it makes grain and relationships explicit.
Gold does not have to mean one giant enterprise model. It can be domain-oriented, provided the domains use clear definitions and shared dimensions where consistency matters.
Choose lakehouse or warehouse by workload, not by layer color
Fabric supports more than one way to implement medallion architecture. A team can use lakehouses for all layers, or use lakehouses for bronze and silver with a warehouse serving the gold layer. Structured SQL-first workloads can also justify warehouse-heavy designs.
The choice should follow processing style and consumer needs. Spark-heavy engineering, semi-structured data, and data science may favor lakehouse capabilities. SQL-centric transformation, relational serving, and conventional BI teams may prefer a warehouse for curated consumption.
Understanding data warehouse architecture helps prevent a false choice between “modern lakehouse” and “old warehouse.” In Fabric, the two can participate in one OneLake-centered analytical system.
Make layer boundaries enforce different permissions
A layer boundary is stronger when it changes who can do what. Most analysts should not need write access to raw ingestion or intermediate transformation layers. They need dependable access to curated data products and semantic models.
Separating layers into different workspaces can support clearer ownership and governance, especially when bronze and silver contain sensitive or operationally fragile data. A single workspace can be simpler, but it demands stronger discipline around permissions, naming, and deployment.
Ask what failure you are trying to prevent. If accidental analyst changes to engineering assets are a real risk, physical and permission boundaries are worth more than a perfectly tidy workspace list.
Design for replay and recovery before the first incident
A medallion design should answer how data is reprocessed when logic changes. If bronze retains source evidence and silver transformations are deterministic, the team can rebuild curated outputs without asking the source system to reproduce historical data.
Recovery is harder when layers overwrite one another or when business transformations exist only inside a report. Keep raw history for the period the business and compliance context requires, version important logic, and make the path from source to gold repeatable.
The ability to replay a range of data also makes testing safer. Engineers can validate a new transformation against a known historical slice before promoting it broadly.
Do not turn medallion into three copies of everything
The pattern can become expensive if every layer blindly materializes every field for every source. Refinement should have purpose. Bronze preserves evidence, silver creates reusable trustworthy entities, and gold serves concrete analytical needs. If a dataset does not need a gold representation, do not create one just to complete the diagram.
Shortcuts can reduce unnecessary copies when data already resides in supported storage. Materialized lake views and other Fabric features can also help manage dependencies and refresh behavior. The architectural question is still the same: what contract does each layer provide?
Storage cost is only part of the problem. Extra copies also create more refresh jobs, security surfaces, and objects that someone must own.
Let semantic models consume stable business grain
The semantic layer should not have to repair unstable engineering outputs on every refresh. If a report model repeatedly deduplicates customers, repairs keys, or rebuilds complex business entities, the silver or gold layer is probably under-designed.
Strong data modeling begins before Power BI. Grain, keys, conformed dimensions, slowly changing behavior, and historical rules should be deliberate in the curated layer so semantic models can focus on measures, relationships, and user-friendly terminology.
This also improves reuse. Several semantic models can share a trusted gold entity without each team independently rebuilding the same cleansing logic.
Measure the architecture by analyst friction
A technically elegant medallion design can still fail if analysts spend hours discovering which gold table is trustworthy, joining incompatible dimensions, or reconciling competing definitions. The architecture should reduce those tasks, not merely relocate them.
Track the number of repeated transformations in reports, support requests about data meaning, conflicting KPI definitions, and the time needed to onboard a new analyst. Those signals expose whether the layers are creating a usable analytical platform.
Analysts also need service expectations for each layer. Bronze can be complete but not yet validated; silver can be trustworthy at an entity level but not optimized for reporting; gold can promise a particular refresh cadence and business grain. Publishing those expectations prevents users from choosing a layer simply because it is the first place they found the field they wanted.
Fabric supports materialized lake views as one way to express transformations and dependencies across medallion layers. Their value is not that they remove architecture decisions; it is that they can make dependency management, refresh behavior, monitoring, and data-quality rules more declarative. Teams should still decide what belongs in bronze, silver, and gold before choosing the mechanism that moves data between them.
Physical maintenance matters as the lakehouse grows. Many tiny files can increase metadata and file-operation overhead, while very large files can be inconvenient for some write patterns. The correct target depends on layer and workload, so engineers should monitor file distribution and query behavior instead of treating the raw landing pattern as permanent. The curated layers deserve storage layout that matches the engines and users that consume them.
Medallion designs also need an answer for schema evolution. New source columns, changed types, and renamed fields should not silently propagate through all three layers. Bronze can preserve the new source shape, silver can reconcile it into a stable entity contract, and gold can expose the change when analytical consumers are ready. That separation is one of the pattern’s strongest benefits when the source estate changes frequently.
Finally, avoid using layer names as a substitute for data-product ownership. A gold table with no owner, definition, freshness target, or support path is still hard to trust. The most useful curated datasets behave like products: their consumers are known, breaking changes are managed, and quality failures have an accountable response.
A useful analyst-facing contract also defines what should never happen in gold. Surrogate technical keys, source-specific status codes, and raw ingestion metadata may be necessary upstream but should not become the primary language of reporting when clearer business attributes exist. Curated layers should reduce the number of technical implementation details every analyst must memorize.
When a gold table changes grain, treat that as a breaking change. Adding a column is often safe; changing one row per order into one row per order line can invalidate measures and joins even if the table name stays the same. Medallion architecture works best when curated interfaces are versioned with the same care as application APIs.
Medallion architecture is not finished when data reaches gold. It is finished when the gold layer makes correct analysis easier than incorrect analysis.
Design bronze for evidence, silver for reusable reliability, and gold for analytical clarity. When those contracts are explicit, engineers get a system they can operate and analysts get data they can understand without reverse-engineering the pipeline.