Beyond the Medallion: Building Fabric Data Products with Schemas, Materialized Lake Views, and a “Surface Area” Contract

If you’ve been around modern analytics platforms for more than five minutes, you’ve probably built (or inherited) a medallion architecture: bronze → silver → gold. It’s familiar, it’s easy to draw on a whiteboard, and it’s often the first stable pattern teams reach for.

But there’s a quiet problem hiding in that simplicity: the number of sublayers tends to grow, and the complexity of each layer tends to balloon. Before long, you’re not designing a data product—you’re running an assembly line of multi-step transforms, hand-managed orchestration, and fragile dependencies.

Microsoft Fabric is starting to give us a different move: instead of treating transformation as a few “big” layers, you can treat it as a series of small, composable steps—and let the platform manage the dependency graph.

In this article, I’m going to connect three ideas:

• Lakehouse schemas as your unit of organization (and the boundary between “internal plumbing” and “published contract”)
• Materialized Lake Views as the declarative engine that builds (and refreshes) a dependency graph for you
• A surface area schema designed to be shortcutted into other workspaces—so each workspace becomes an “analytical microservice” with its own interface, security boundary, and versioning story

Along the way, we’ll introduce a pragmatic versioning approach: create a new schema for major versions so breaking changes get semantic versioning “for free.”

The medallion was never the point

The medallion architecture is best understood as a direction, not a fixed number of tiers:

• raw data becomes cleaner
• cleaner data becomes modeled
• modeled data becomes useful to many consumers

What breaks down in practice is when the architecture becomes a rigid physical structure, where every change must route through the same multi-layer pipeline. The result is a few huge transforms, large blast radius, and a lot of orchestration glue.

Fabric’s newer primitives push you toward a different shape: many small transforms, each with clear intent, with refresh and dependency ordering handled by the platform.

That’s where “beyond the medallion” starts to matter—not because bronze/silver/gold is wrong, but because it’s too coarse for the way real data products evolve.

Schemas change the unit of design

Lakehouse schemas in Fabric aren’t just cosmetic folders. They’re a way to group tables intentionally for discoverability and (crucially) for access control and product boundaries. Microsoft’s own documentation frames schemas as a way to group tables “for better data discovery, access control, and more.”

This sounds basic—until you realize what it enables:

• You can keep internal, intermediate artifacts out of sight (or at least out of the “happy path” for consumers).
• You can name things like you mean it: not gold_sales_final_v7, but sales.surface.
• You can treat the schema itself as a contract boundary.

Fabric also supports schema shortcuts, which is a big deal for composability. A schema shortcut can reference multiple Delta tables from another Fabric lakehouse (or a folder of Delta tables), and Fabric will surface them under a schema in the consuming lakehouse—with changes in the source appearing in the shortcut schema.

That one feature is the hinge for the “surface area schema” idea.

Materialized Lake Views: declarative steps with an autogenerated dependency graph

Materialized Lake Views (MLVs) in Fabric are precomputed, stored results of SQL queries. You define the transformation in SQL, and Fabric materializes it as a persisted object that can be refreshed on demand or on a schedule.

The important part isn’t just performance—it’s operability.

Fabric’s MLV capabilities include:

• Refresh optimization, including incremental refresh, full refresh, or skipping refresh when source data hasn’t changed
• Dependency management, including a visualization of dependencies and automatic refresh ordering based on those dependencies
• Built-in data quality constraints you can declare directly in SQL

When you create MLVs that reference each other, you’ve effectively declared a DAG of transformations—and Fabric can execute that graph in dependency order.

In the “get started” flow, Fabric explicitly calls out that the lineage is autogenerated, and you can schedule the lineage execution.
In the medallion tutorial, it’s even more direct: the lineage view is autogenerated based on dependencies, and each dependent MLV forms nodes in the lineage.

That’s the core “beyond the medallion” shift:

Instead of building three big layers, you can build ten small steps—and still keep your pipeline understandable, refreshable, and governed.

A quick reality check: MLVs are currently in preview, and there are limitations—most notably that cross-lakehouse lineage and execution features aren’t available (at least as described in the current documentation).
That matters for the microservice pattern (we’ll handle it intentionally), but it doesn’t diminish the value inside a workspace.

A simple ingestion pattern built from small steps

Here’s the mental model I like: stop thinking “bronze/silver/gold” as three destinations, and start thinking “ingest → refine → publish” as a chain of small contracts.

With schemas and MLVs, a lakehouse can look like this:

• ingest schema: raw tables (or lightly structured landing tables)
• core schema: cleaned/conformed entities (small, testable transforms)
• surface schema: the published interface that other workspaces depend on

And you make each step small enough that it can be read and reasoned about.

A simplified illustration (not meant as a copy/paste solution, but as a pattern):

CREATE SCHEMA IF NOT EXISTS ingest;
CREATE SCHEMA IF NOT EXISTS core;
CREATE SCHEMA IF NOT EXISTS surface_v1;

-- ingest: raw landing tables exist here

-- core: clean and conform
CREATE MATERIALIZED LAKE VIEW core.orders_clean AS
SELECT ...
FROM ingest.orders_raw
WHERE ...;

CREATE MATERIALIZED LAKE VIEW core.customers_clean AS
SELECT ...
FROM ingest.customers_raw;

-- surface: publish stable, business-facing shapes
CREATE MATERIALIZED LAKE VIEW surface_v1.orders AS
SELECT ...
FROM core.orders_clean;

CREATE MATERIALIZED LAKE VIEW surface_v1.customer_orders AS
SELECT ...
FROM core.orders_clean o
JOIN core.customers_clean c
  ON o.customer_id = c.customer_id;

The win is not that this is “more layers.” The win is that each transform is single-purpose, and the platform can manage dependency ordering and refresh strategy. There’s also a small bonus that many of the things you might have been reusing CTEs for, you can just make a stored MLV, and now instead of computing them once per query, you’re computing them once per refresh.

This is where Microsoft Fabric starts to feel less like “a place to run notebooks” and more like a platform for data engineering with opinions.

The “surface area schema” as a product contract

Now we can make the idea explicit:

Your surface area schema is the only schema you expect other data products to depend on.

Everything else is internal.

This changes how you design:

• The surface schema contains curated entities, conformed dimensions, and reporting-friendly fact shapes.
• It avoids “maybe-useful” intermediates.
• It favors stability over convenience.

Then you design it to be shortcutted.

Fabric’s schema shortcuts allow a consuming lakehouse to reference all tables under a chosen schema (or folder) from another lakehouse.
That means your surface schema can function like an API: downstream workspaces can “mount” it without copying data.

This is where data mesh ideas become practical without turning into philosophy: each workspace can own its product, but still compose with others through a deliberate interface.

OneLake security makes composition safe

Composition without security is just accidental data sharing.

OneLake security introduces an RBAC model where the scope can be tables, folders, or schemas.
It also uses a deny-by-default model: users start with no access unless explicitly granted by a role.

Two details matter a lot for the “analytical microservice” idea:

• Workspaces are the first security boundary for data in OneLake.
• With OneLake-to-OneLake shortcuts, Fabric supports passthrough behavior (identity passes through), and the source system retains control—downstream items can’t modify security for those shortcuts; changes must be made at the source.

Put that together and you get a clean pattern:

• In the producing workspace, grant broad access internally (or not), but grant external consumer access only to surface_* schemas.
• In the consuming workspace, use a schema shortcut to bring in the surface schema.
• Let passthrough and source-owned permissions enforce the contract across workspaces.

This is the OneLake story that’s easy to miss: security isn’t just a governance checkbox—it’s what makes workspace-level composability viable.

(As with MLVs, note that OneLake security is currently in preview.)

Workspaces as “analytical microservices”

Once you have:

• a surface area schema as the interface
• internal schemas as implementation details
• MLVs as the declarative transformation DAG
• OneLake security as the boundary

…a Fabric workspace starts to look a lot like an analytical microservice:

• it has a clear purpose
• it owns its own data and transformation logic
• it exposes a stable interface (surface schema)
• it can be composed by other workspaces without tight coupling

This is also where versioning and publishing stop being “process” and start being “design.”

Fabric supports Git integration at the workspace level, enabling teams to back up and version their work, collaborate with branches, and manage Fabric items with source control.
And Fabric’s deployment pipelines provide a structured way to clone and promote content across stages (typically dev → test → prod).

Those tools don’t replace schema-based versioning—but they complement it:

• Git/deployment pipelines version and promote implementation
• Surface schemas version and communicate contracts

Semantic versioning by schema name

Here’s the practical move that tends to land well with real teams:

Use schema names to represent major versions of your published interface.

For example:

• surface_v1 — current contract
• surface_v2 — breaking changes land here

When you need a breaking change (rename a column, change grain, remove a table, redefine business logic), don’t “fix” surface_v1. Publish surface_v2.

Consumers shortcut to the schema they’re ready for:

• Existing consumers stay pinned to surface_v1
• New consumers adopt surface_v2
• Migration becomes an explicit decision, not a surprise outage

Minor and patch changes become calmer:

• Minor version: additive changes inside the same major schema (new tables, new columns that don’t break)
• Patch version: bug fixes in MLV logic that preserve the contract shape (same schema, same object names)

Because schemas are first-class in Fabric lakehouses, and because schema shortcuts can reference an entire schema, this versioning approach fits the platform rather than fighting it.

It’s also the simplest way to make “semantic versioning” real for data products, where the consumers are often many, distributed, and not in lockstep.

Wrapping up

Let’s rewind to the promise we started with.

Going “beyond the medallion” in Fabric isn’t about rejecting bronze/silver/gold. It’s about building data products that are:

• modular (small transforms, chained together)
• operable (dependencies and refresh ordering managed by the platform)
• composable (surface schemas shortcutted across workspaces)
• secure by design (OneLake roles scoped to schemas; passthrough shortcuts where appropriate)
• versionable (major versions expressed as new surface schemas)

Materialized Lake Views give you a declarative transformation engine with dependency-aware refresh and lineage.
Lakehouse schemas give you a clean way to separate internal implementation from published interface—and schema shortcuts give you a direct mechanism to compose products.
OneLake security gives you the boundary that makes “workspace as microservice” more than a metaphor.

If you want a concrete next step: pick one existing medallion pipeline and refactor it around a surface schema contract. Break the transforms into smaller MLV steps, lock down internal schemas, and let consumers shortcut the surface. You’ll feel the difference immediately—in change management, in clarity, and in how quickly teams can build on top of each other without stepping on each other.