Materialized Lake Views in Microsoft Fabric: your medallion pipeline in a few lines of SQL

Data engineering on a lakehouse used to mean a lot of moving parts. A notebook for each transformation layer. A Data Factory pipeline to run them in the right order. Custom validation logic across scripts. Schedules to maintain and a Monitor Hub to watch when things break. Five different surfaces and five different things to debug when something goes wrong.

Materialized Lake Views (MLVs) in Microsoft Fabric change that story. Instead of managing all those pieces separately, you write a SQL transformation and let Fabric handle execution, storage, refresh scheduling, dependency ordering, and data quality

Introduced in preview at Microsoft Build 2025, MLVs reached general availability in March 2026 production-ready and significantly expanded. In this post, we walk you through everything you need to know: What MLVs are, how they work, what changed at General Availability, and where they fit in your architecture.

What Are Materialized Lake Views?

A Materialized Lake View is a persisted, automatically refreshed view defined using Spark SQL or PySpark. You write a SELECT query that describes the transformation you want an aggregation, a join, a filter and Fabric stores the result as a Delta table in your Lakehouse.

In plain terms: An MLV is a SELECT statement that has learned to materialize itself, manage its own dependencies, schedule its own refresh, and enforce its own data quality.

Because the result lives as a standard Delta table in OneLake any downstream consumer: Power BI, Spark notebooks, SQL endpoints can query it directly, from their perspective it looks and behaves like any other table and because it’s a Delta table you can connect Power BI via Direct Lake straight away.

You can recognize an MLV in the Fabric interface by the lightning bolt icon next to the table name.

How Materialized Lake Views Work

The lifecycle of a Materialized Lake View moves through four stages:

1. Create

You define the MLV using a Spark SQL transformation query (or PySpark, since general availability). When executed Fabric runs the query, stores the result as a Delta table and tracks dependencies with the source tables automatically.

2. Refresh

When source data changes Fabric determines the optimal refresh strategy automatically. Three outcomes are possible:

• Incremental refresh:  only new or changed data is processed
• Full refresh:  the entire dataset is recomputed
• Skip:  no changes detected, no refresh needed

A built-in decision engine evaluates each refresh weighs the volume of changed data against the cost of a full recompute and picks the faster path. You don’t configure this manually Fabric handles it.

To enable incremental refresh source tables must support Delta Change Data Feed (CDF). Once enabled Fabric tracks row-level changes and processes only what is new or modified.

3. Query

MLVs can be queried exactly like regular tables because they are regular tables. The transformation results are already stored so queries are significantly faster than executing the original logic each time.

4. Monitor

Fabric provides built-in monitoring for every MLV: refresh history, execution status, data quality metrics and full dependency lineage. The lineage view shows source tables, downstream assets, refresh order and dependency relationships extremely useful for impact analysis and data governance.

Extended Lineage and Cross-Lakehouse Execution

As of May 2026 Fabric introduced extended lineage, a significant upgrade to the standard lineage view. Standard lineage shows dependencies one level deep within your current lakehouse. Extended lineage traces every dependency recursively across multiple lakehouses, including lakehouses in other workspaces.

More importantly this unlocks cross-lakehouse execution. You can now define all your MLV logic in a single Gold lakehouse while referencing source tables from Bronze and Silver even across different workspaces. Fabric handles the cross-lakehouse reads during refresh, so you maintain one set of definitions instead of duplicating transformation logic across lakehouses.

From the extended lineage view, you can also schedule refreshes for upstream MLVs in other lakehouses without navigating to each one separately.

What Changed at General Availability (March 2026)

The general availability release closed the most critical gaps from the preview and made MLVs suitable for production workloads at scale. Five major improvements stand out:

1. Multi-Schedule Support

In preview all MLVs in a lakehouse shared a single refresh schedule. Teams with multiple data products at different cadences worked around this with notebook-triggered refreshes bypassing dependency management, error reporting and retry logic. Failures could persist undetected for weeks.

Now you can define multiple named schedules within a single lakehouse, each targeting a specific subset of views. A finance pipeline can refresh hourly while an analytics pipeline runs every six hours no scripting required. When a schedule fires Fabric refreshes upstream dependencies in order, runs independent views in parallel, surfaces errors centrally and skips overlapping runs.

2. Broader Incremental Refresh

Incremental refresh previously covered a limited set of SQL patterns. At general availability MLVs can now refresh incrementally when the definition includes:

• Aggregations such as COUNT and SUM with GROUP BY
• LEFT OUTER JOINS and LEFT SEMI JOINS
• Common Table Expressions (CTE’s)

These additions mean that most real-world medallion pipelines qualify for incremental processing without any rewriting a significant performance and cost improvement for large datasets.

3. PySpark Authoring

SQL is powerful, but not always sufficient. When your transformation involves custom Python libraries, ML inference calls or complex UDFs (custom functions), SQL-only MLVs hit a wall. PySpark authoring removes that constraint.

You can now create, refresh and replace MLVs from Fabric notebooks using PySpark and the familiar DataFrameWriter API including data quality constraints, table properties, and scheduled refreshes. The entire pipeline from raw ingestion to a production-quality gold layer, can live in a single notebook.

Important: PySpark MLVs currently perform a full refresh on every run. Incremental (optimal) refresh support for PySpark is on the roadmap but not yet available.

4. In-Place Updates

Transformation logic changes. Using CREATE OR REPLACE you can update an existing MLV’s definition without breaking downstream dependencies. Fabric updates the transformation logic, rebuilds the materialized dataset and maintains existing lineage relationships in the process.

5. Stronger Data Quality Controls

Data quality constraints can now be declared directly in the MLV definition no separate validation logic required. You define the rule, specify what happens on a violation and Fabric applies it during every refresh. Possible actions include dropping invalid rows, failing the refresh job or logging validation results to the built-in metrics table.

MLVs and Direct Lake in Power BI

One of the most powerful combinations in the Fabric ecosystem is Materialized Lake Views paired with Direct Lake mode in Power BI.

Direct Lake allows Power BI semantic models to query Delta tables stored in OneLake without importing the data or using DirectQuery. The engine reads directly from the lakehouse storage layer delivering import-mode speed with the freshness of a live connection.

Because MLVs are physically stored as Delta tables they are fully compatible with Direct Lake. Your Power BI reports query pre-computed always-refreshed data at high speed with no additional configuration needed.

Best practice: Use MLVs as your curated gold layer in a medallion architecture and connect your Power BI semantic models via Direct Lake. You get the performance of import mode and the data freshness of DirectQuery — without the trade-off.

When to Use Materialized Lake Views

MLVs are the right choice when:

• Your datasets are large and queries are computationally expensive
• Transformations are queried frequently by downstream consumers
• You want to keep your pipelines SQL-based and declarative
• You want automatic incremental processing without custom orchestration
• You need built-in data quality checking without separate validation logic
• You are building or refactoring a medallion architecture on Fabric

MLVs are less suitable for real-time streaming scenarios requiring sub-second updates, machine learning pipelines with complex Python transformations or one-time queries that don’t benefit from precomputed results. For those cases consider Fabric Real-Time Intelligence or standard Spark notebooks respectively.

MLV vs View vs Delta Table

Feature	Materialized Lake View	View	Delta Table
Data storage	Physically stored (Delta files)	Not stored	Stored
Query execution	Precomputed results	Recomputed every time	Direct table access
Refresh mechanism	Automatic (incr./full/skip)	No refresh	Manually managed
Data quality rules	Built-in via constraints	Not supported	Custom logic required
Lineage tracking	Automatic	Limited	Limited
Performance	High	Depends on query	High
Direct Lake compatible	Yes	No	Yes

Going Further: Our Own CI/CD Framework for MLV Deployments

Knowing what MLVs can do is one thing. Fitting them into a real delivery pipeline is another. That is exactly what our data engineer Sam Corbeel tackled by building an internal deployment framework that brings CI/CD discipline to MLV management across environments.

The problem it solves

When managing MLVs across DEV and PROD one question comes up fast: how do you know which definitions changed since the last deployment? Our framework answers it by storing MLV definitions as SQL files and hashing them at every run. On each deployment it compares current hashes against what is stored and acts accordingly: CREATE if new, REPLACE if changed, Skip if identical, DROP if removed.

The setup is minimal: a medallion structure, two notebooks, and one pipeline. The Deployment Notebook runs the hash comparison, the Refresh Notebook handles the actual data refresh afterward.

What this delivers

·       Version-controlled MLV definitions in source control

·       Portable deployment logic across DEV and PROD

·       Smarter deployments that only touch what changed

One honest trade-off

The custom refresh notebook meant losing native Fabric behaviors: optimal incremental refresh and dependency-aware ordering. Sam’s own recommendation is to drop the custom Refresh Notebook and let native Fabric scheduling take over after deployment  our framework handles the deployment, Fabric handles the rest.

Closing: Your Pipeline Is a Few SELECT Statements Away

Materialized Lake Views are not just another feature update. They represent a fundamental shift in how data pipelines are built on Microsoft Fabric.

The complexity of notebooks, orchestration pipelines, custom validation scripts and fragmented monitoring collapses into declarative SQL. You describe the transformation you want. Fabric handles execution, storage, refresh, dependency management and data quality automatically.

With the general availability release MLVs are now production-ready: multi-schedule support, broader incremental refresh, PySpark authoring, in-place updates and stronger data quality controls make them a solid foundation for the most demanding enterprise pipelines.

If you are running a lakehouse on Fabric and managing transformation notebooks manually today Materialized Lake Views are worth a serious look.

Curious how MLVs fit your Fabric environment? Our team is happy to help, from an architecture conversation to a hands-on proof of concept. Get in touch and let’s explore it together!

Written by