What a materialized lake view actually is#
A materialized lake view (MLV) in Fabric is a persisted, auto-refreshed view defined in Spark SQL or PySpark, expressing medallion-architecture (bronze/silver/gold) transformations declaratively instead of hand-written Spark jobs [S1]. The key word is persisted: unlike a regular SQL view, which recomputes on every query, an MLV stores its result as a physical Delta table in OneLake, so later reads consume the pre-computed table instead of re-running the query [S2]. That means Power BI reports can read an MLV's result immediately, without waiting on transformation logic at query time — useful when many people query the same report at once [S2].
This is why MLVs map naturally onto the medallion pattern: bronze holds raw data, silver holds cleaned data, and gold holds business-ready aggregates, each layer its own MLV, with Fabric handling the movement between them with little manual orchestration [S2]. Across a lakehouse, Fabric tracks dependencies between every MLV, refreshes them in the correct order, runs independent views in parallel, and enforces attached data-quality rules — all visible from one monitoring surface [S1].
How refresh works#
Each refresh, Fabric chooses between an incremental refresh (updating only new/changed data) or a full refresh (recomputing everything), and skips the refresh entirely if nothing upstream changed [S2]. Spark SQL authoring gets the fuller treatment: incremental refresh covers common shapes like GROUP BY aggregations, left outer/semi joins, and common table expressions [S1]. PySpark authoring, via the DataFrameWriter API, targets logic needing custom Python cleansing, UDFs, or procedural steps mixed with DataFrame operations — but PySpark-authored MLVs currently run full refresh only every time; incremental refresh for them is a stated future capability, not available yet [S1].
A worked example#
You're building a sales lakehouse. A bronze MLV lands raw order records as-is. A silver MLV, in Spark SQL, filters cancelled orders and standardizes currency — being SQL-expressible, it qualifies for incremental refresh, so only new orders get reprocessed each run [S1]. A gold MLV aggregates silver into daily revenue totals with a GROUP BY, also incrementally refreshable [S1]. A Power BI report reads gold directly, with no wait for transformation logic, even while colleagues view the same report concurrently [S2].
What goes wrong#
- Expecting PySpark MLVs to refresh incrementally. They're full-refresh only for now — fine at small scale, expensive at large scale [S1].
- Reaching for MLVs on everything. For very complex business logic, Python-heavy processing, or live streaming data, Spark notebooks or Data Factory pipelines remain the recommendation; MLVs suit standard SQL-expressible transformations [S2].
- Assuming a query-time view and an MLV behave the same. An MLV's result is stored, not recomputed per query — the freshness you see depends on when it last refreshed, not when you queried it [S2].