Materialized Lake Views in Microsoft Fabric: persisted transformations for Lakehouses
Microsoft Fabric's Materialized Lake Views persist Lakehouse transformations as Delta tables, letting Fabric decide how each view refreshes and enforcing data quality constraints along the way. The article walks through how MLVs fit Bronze, Silver and Gold layers, which refresh strategies apply, and where they fall short. Read it if your Fabric pipelines are stitched together from notebooks and orchestration jobs.
Key points
- MLVs are defined with SQL or PySpark and materialized as Delta tables in a Lakehouse.
- Fabric automatically chooses incremental, full or skip refresh based on source changes.
- Incremental refresh requires Delta Change Data Feed to be enabled on source tables.
- PySpark-authored MLVs currently support full refresh only, according to the documented capabilities.
- CHECK constraints with ON MISMATCH DROP filter out bad rows before they reach downstream tables.
- Refresh history, data quality metrics and lineage show pipeline health; _mlv_system tables should not be modified manually.
Microsoft Fabric's Materialized Lake Views (MLVs) address a common pain in Lakehouse work: chains of Spark jobs and orchestration code that must stay in step. An MLV is defined declaratively in SQL or PySpark, and Fabric stores the result as a Delta table, so downstream consumers read precomputed data instead of rerunning the query each time.
Fabric picks a refresh strategy per view: incremental processing, a full rebuild, or a skip when nothing relevant changed. Incremental refresh requires Delta Change Data Feed on the source tables, and PySpark-authored views currently support only full refresh. CHECK constraints with ON MISMATCH DROP enforce data quality inside the transformation, while refresh history and lineage help monitor Bronze, Silver and Gold chains. Heavy Python logic or streaming work still fits better in notebooks or other tools.
Real-world use
- A sales Lakehouse that reads raw CSV files from OneLake, cleans them into a Silver table and totals revenue by region in Gold.
- A nightly reporting pipeline where dependent aggregations refresh in the right order without custom orchestration code.
- A data team that enforces positive amount or required-field rules centrally instead of repeating them in every notebook.
Why it matters
If your Fabric pipelines are chains of notebooks and copy jobs, MLVs can replace some orchestration code with declared dependencies and refresh logic. Check the PySpark full-refresh limit and the CDF requirement before migrating.