Materialized Lake Views in Microsoft Fabric: Stop Orchestrating, Start Declaring
The Challenge
Every data engineer running a medallion architecture in Fabric has the same conversation at some point: "Why am I spending more time managing notebook schedules than writing actual transformations?"
It's a fair question. The pattern is well-established — bronze ingests raw data, silver cleans and conforms it, gold aggregates for reporting. But the implementation? That's where teams get tangled. You write Spark notebooks for each transformation. You wire them into pipelines. You manage execution order, handle retries, deal with failures halfway through a chain of six dependent jobs. And somewhere in all that plumbing, the data quality checks get added as an afterthought — if they get added at all.
The orchestration overhead is real. For many teams, it represents 40–60% of their data engineering effort. Not transforming data. Managing the infrastructure that transforms data.
What's Changed
Materialized Lake Views (MLVs) in Microsoft Fabric take a different approach. Instead of imperative notebook code wired through pipeline activities, you write a SQL definition that describes what you want. Fabric handles when and how it runs.
Here's what that looks like in practice:
CREATE MATERIALIZED LAKE VIEW IF NOT EXISTS silver.customers_enriched
(CONSTRAINT cust_blank CHECK (customerName IS NOT NULL) ON MISMATCH DROP)
AS
SELECT
c.customerID,
c.customerName,
c.contact,
CASE
WHEN COUNT(o.orderID) OVER (PARTITION BY c.customerID) > 0 THEN TRUE
ELSE FALSE
END AS has_orders
FROM bronze.customers c
LEFT JOIN bronze.orders o ON c.customerID = o.customerID;
Three things are happening in that single statement. First, a transformation: joining customers with orders and computing a flag. Second, a data quality constraint: any row where customerName is null gets dropped, not failed silently into downstream tables. Third, the result is persisted as a Delta table in OneLake — query-ready, versioned, and trackable through Fabric's lineage view.
The January 2026 update added CREATE OR REPLACE semantics, so you can evolve your view definitions — adding columns, changing logic, updating constraints — without dropping and recreating. Lineage enhancements in the same release mean you can trace exactly which MLVs depend on which source tables, and which downstream reports consume them.
Refresh happens automatically via schedules or event triggers. You define the transformation. Fabric figures out the execution plan, optimises the refresh, and handles the mechanics. For frequently accessed aggregations — daily sales totals, monthly metrics, complex multi-table joins — this eliminates the notebook-pipeline-schedule dance entirely.
Getting Started
MLVs are currently in public preview, which means you can start experimenting today in any Fabric workspace (except South Central US, where the feature isn't available yet).
The practical starting point is identifying your simplest silver-layer transformations — the ones that are just SQL joins with maybe a filter or two. These are the easiest wins. You don't need to migrate your entire medallion architecture in one go. Start with one view, validate it produces the same output as your notebook, then let it run on a schedule for a week before expanding.
The data quality constraints are particularly worth testing early. Most teams I work with bolt quality checks on as a separate pipeline step — a notebook that runs after the transformation to flag bad records. With MLVs, the constraint is part of the view definition itself. If a row violates the check, it's dropped (or the refresh fails, depending on your configuration) before it ever lands in the output table. One word of caution: the FAIL action has a known issue where it can produce "delta table not found" errors. Microsoft's own documentation recommends using DROP instead until this is resolved.
To get hands-on, the Microsoft Learn documentation covers the full syntax, and the YouTube walkthrough demonstrates the end-to-end flow.
What This Means
MLVs signal a broader shift in Fabric's data engineering story: from "write code and schedule it" to "define what you want and let the platform handle the rest." It's the same declarative pattern that made dbt popular in the modern data stack — but native to Fabric, persisted as Delta, and integrated with the platform's lineage, monitoring, and refresh infrastructure.
This isn't a replacement for Spark notebooks. Complex Python or Scala transformations, ML feature engineering, anything that needs procedural logic — those still live in notebooks. But for the 60–70% of medallion transformations that are fundamentally SQL, MLVs eliminate a category of operational complexity that most teams accepted as unavoidable.
Combined with the Native Execution Engine and the Osmos acquisition for agentic data engineering, the direction is clear: Fabric wants data engineers spending time on data problems, not plumbing problems. MLVs are the first concrete step in that direction.
Leon Godwin, Principal Cloud Evangelist at Cloud Direct