A schema change is rarely “just a schema change.”
It’s the moment an upstream team’s perfectly reasonable adjustment becomes a downstream team’s broken report, confusing metric, or silent misinterpretation. And that’s why schema evolution has always been a source of anxiety: a schema isn’t simply structure—it’s an interface.
In this post, I’ll do three things. First, I’ll ground why schema evolution has historically been such a persistent concern. Next, I’ll reframe Medallion with Gold as the published surface area of the data product, and Silver as an optional workshop layer where data is supplemented and transformed. Finally, I’ll connect that design to how Microsoft Fabric supports it today—especially the post‑Ignite direction around governance, security, and semantics.
Why schema evolution has always been a big concern
The older warehouse worldview made an implicit promise: once you modeled the business, the model would hold still. That stability is exactly what made the warehouse valuable—but it also made change costly.
The core issue isn’t technical. It’s architectural and social:
- Schemas create coupling. Producers and consumers coordinate through a shared shape and shared meaning.
- Coupling creates fragility. If consumers bind directly to upstream structure, the smallest upstream change becomes everyone’s emergency.
- Meaning drifts faster than structure. Even when pipelines don’t fail, semantics can drift: a column remains, but what it represents subtly shifts.
As data platforms broadened to include APIs, files, event streams, and vendor‑provided extracts, schema drift stopped being exceptional. It became routine. The best modern architectures don’t try to outlaw change. They decide where change can safely land, where it is interpreted, and where it is published as a dependable contract.
That’s the deeper value of the lakehouse pattern: it doesn’t remove evolution—it gives it a place to happen.
Reframing Medallion: Bronze records, Silver works, Gold publishes
Microsoft’s own Fabric guidance describes Medallion as a recommended design approach, with three layers: bronze (raw), silver (enriched), gold (curated). It also frames the layers as progressively improving quality—raw → fixed/standardized → organized for reporting.
That baseline definition is important, because it clarifies roles. But if you’re approaching the platform with data-product thinking, there’s a useful refinement:
Gold is the surface area of the data product.
Gold is what you intend other people (and tools) to depend on. It’s the “public interface” you publish, version, secure, document, and support. Fabric’s Medallion guidance explicitly positions Gold as “Organize for reports and dashboards,” which is another way of saying: this is where consumption happens.
Silver is the optional workshop.
Silver becomes the place where you supplement, augment, and transform in service of Gold. Many products need this workshop: deduplication, standardization, enrichment, conformance across sources. Fabric even describes Silver as the layer to “fix errors, standardize formats, and remove duplicates.”
But the key word here is optional—not because Silver is unimportant, but because not every Gold product requires a distinct intermediate layer. Some data products are essentially “well-governed raw” plus light curation. Others need significant supplementation. Silver exists to serve the product contract, not to satisfy an architectural checkbox.
Bronze remains your source-of-truth capture.
Bronze is still where you “store everything exactly as it arrives.”
That matters because it keeps your system honest. When a schema changes upstream, Bronze captures reality without forcing an immediate contract change downstream.
This is how the architecture makes schema evolution feel “built-in”: it creates a natural promotion path from observedchange (Bronze) to prepared change (Silver, if needed) to published change (Gold).
Fabric makes the layers real by standardizing the storage and surfacing the contract
A lot of “schema evolution strategies” collapse under platform inconsistency—one engine writes one format, another reads another, and governance lives somewhere else. Fabric’s direction is explicitly toward reducing that fragmentation.
Fabric Lakehouse uses Delta Lake as the default and preferred table format, emphasizing consistent integration and performance across Fabric services.
This matters because a stable product surface (Gold) requires stable storage behaviors underneath it.
And because data products are about a published interface, the consumer experience matters just as much as the pipeline mechanics. Power BI’s Direct Lake mode is part of that story: it allows OneLake data to be visualized in Power BI without duplicating data, and supports creating semantic models over Lakehouse or Warehouse artifacts.
If Gold is your product surface, then “Gold” isn’t just a table—it’s often a combination of curated tables and the semantic experience through which most users actually consume them.
Handling schema evolution in Fabric, layer by layer
Here’s the practical way to think about schema change when Gold is the data product contract.
Bronze: absorb change without pretending it’s ready
Bronze is where variability belongs. This includes the simple reality that files change. Fabric’s Medallion guidance explicitly recommends storing Bronze data in its original format and using shortcuts instead of copying where appropriate.
Two Fabric capabilities are especially aligned with Bronze’s “absorb and record” posture:
- Dataflow Gen2 schema drift handling: Fabric documentation describes schema drift (new columns, removed columns, type changes) and notes that Dataflows offer methods like type detection and destination mapping behaviors that adjust as changes occur and are republished.
- Shortcut transformations: These convert raw files (CSV/Parquet/JSON) into Delta tables that stay in sync, with “automatic schema handling,” and—crucially—inherit governance elements like lineage, permissions, and Purview policies.
The important takeaway is not the specific mechanism. It’s the posture: Bronze can accept upstream shape changes without forcing immediate downstream contract changes.
Silver: supplement and augment when the product needs it
When you need to reconcile multiple sources, standardize inconsistent fields, or add derived business attributes, Silver is your workshop.
Fabric’s Medallion guidance describes Silver as the enrichment stage (fix errors, standardize formats, remove duplicates), and it also points to materialized lake views as a way to manage transformations across layers with automatic dependency handling and built-in support for data quality rules.
That’s exactly the right way to interpret Silver in a product-oriented model: Silver is where you do the work that makes the Gold interface coherent.
But it stays internal. It does not need to be the place everyone connects to. If Gold is your contract, Silver is your implementation detail.
Gold: publish the data product interface, and treat schema change as a release
If you want schema evolution to stop being scary, you need a place where schema evolution becomes a managed commitment. In this framing, that place is Gold.
This aligns directly with how Microsoft Purview describes data products: a data product is a business concept with owners and a list of associated data assets, grouped for a consumer use case.
Gold assets—curated tables, semantic models, reports—are the natural candidates for what you package and present as a product.
Purview’s Unified Catalog experience reinforces this idea by organizing discovery through governance domains and describing subscription and access patterns around data products.
So a schema change becomes something much more familiar:
- It is evaluated against the published interface.
- It is communicated as a product update.
- It is governed (ownership, access policy, lineage, and quality expectations).
- It is versioned or deprecated intentionally rather than happening accidentally.
That is the fundamental shift from “schema drift as outage” to “schema evolution as product lifecycle.”
Governance isn’t a separate section—it’s what makes Gold credible
When Gold is your product surface, governance isn’t something you bolt on afterward. It’s part of what you’re publishing.
Two Fabric-adjacent updates since Ignite make this tighter:
OneLake security brings fine-grained enforcement closer to the data.
The OneLake security access control model describes row-level and column-level security filtering applied by Fabric engines, including support status for lakehouse, Spark notebooks, and semantic models using DirectLake on OneLake in public preview.
When your “product surface” includes semantic consumption, that matters: governance can travel with the data into the experience people actually use.
Unified Catalog makes “data product” a first-class governance unit.
Unified Catalog explicitly positions governance domains as boundaries for ownership and scalable policy application, and data products as packaged assets for reuse and access.
In other words: the system is steering you toward an operating model where data products have owners, boundaries, policies, and a discoverable contract.
And Fabric’s own Medallion guidance now directly connects these ideas to data mesh, describing data mesh as focusing on domains offering data as a product, with Fabric domains supporting that approach.
That’s not an accident. It’s the architectural acknowledgement that publishing a stable interface requires both technical structure and organizational clarity.
The post‑Ignite acceleration: semantics becomes part of the contract
Schema evolution isn’t only about columns. It’s also about meaning.
Fabric IQ (preview) workload is explicitly about unifying data across OneLake—including lakehouses, eventhouses, and semantic models—and exposing it with consistent semantic meaning and context.
The ontology (preview) item is described as a way to represent enterprise vocabulary and semantics across domains and OneLake sources, defining entity types, relationships, properties, and constraints, then binding those definitions to real data.
This is important in the Gold-as-contract framing because it raises the bar: the product surface isn’t merely “a stable table.” It’s a stable language. And as organizations push harder into AI-assisted analysis and agent-driven workflows, semantic drift becomes as dangerous as schema drift.
Gold is where you publish the contract. Fabric IQ is part of the emerging story of how you publish the meaning behind it.
Recap: what changes when Gold is the data product surface
Schema evolution has always mattered because schemas are interfaces, and interfaces create coupling. In older patterns, that coupling was direct and brittle. Modern lakehouse patterns make schema change manageable by building in separation: capture reality, prepare it if necessary, then publish a contract.
With Gold as the product surface area, the model becomes clearer:
- Bronze remembers what happened.
- Silver (optionally) does the work needed to make a coherent product.
- Gold publishes the interface others rely on—tables, semantics, and governance included.
Fabric’s Medallion guidance, its Delta-first storage model, its consumption patterns (Direct Lake), its governance direction (Unified Catalog data products and governance domains), and its newer semantic push (IQ/ontology) all reinforce the same idea: schema evolution is not a surprise to be avoided—it’s a reality the architecture is designed to accommodate.
