Why Doesn't a View Work in a Direct Lake Model?

A Fabric user builds a Power BI semantic model on top of a lakehouse, in this case the FUAM lakehouse, and wants to reshape the data. The tables are there, but they need a slightly different shape than the report asks for. The usual reflex is a view in the SQL analytics endpoint, or otherwise a bit of Power Query inside the model itself.

Neither does what he expects. The view doesn't produce a Direct Lake table, Power Query isn't available, and he can't create a calculated column either. On top of that, filtering the report produces capacity warnings and feels slow. The conclusion is an obvious one: Direct Lake is too limited for serious modelling work.

That conclusion is understandable, but it's only half right. Part of what he runs into is a deliberate design choice, part is a symptom of something else failing quietly, and part has since been resolved without the reputation catching up.

The highest rated reply summed up the design intent briefly: the whole idea of Direct Lake is that you model the data using upstream tools and hand Power BI nicely optimized physical tables it can read directly. Either materialize your transformations in the lakehouse, or just use tried-and-true import mode.

Another participant developed that further. If you need a new column, you can't conjure it at query time with a calculated column; that logic belongs upstream and has to land natively in the table. That doesn't mean you can't create anything in the semantic model at all, but Direct Lake works best when the semantic layer stays relatively thin and the heavy transformation work has already been materialized. He also pointed out that expensive model side operations can run into model or capacity resource limits once you've designed around Direct Lake without DirectQuery fallback, instead of simply being pushed down to the source. His summary of the trade: do the expensive data engineering once upstream, rather than repeatedly at query time.

A third reply explicitly named materialized lake views, noting they make materializing far less painful than building a whole new pipeline. The limitation is real, but it's mostly an architectural mismatch rather than Direct Lake randomly lacking functionality.

A practical route also came up that several people recognized: put anything that gets modelled into a warehouse and use the lakehouse only for bronze landing and simple self service. Someone else framed the same thing as a missing layer: you're missing a silver layer, push the staging lakehouse through to a SQL layer in a warehouse and build your report models on top of that. Asked why exactly that makes a difference, the discussion never produced an answer.

The sharpest reply wasn't about technology but about adoption. Someone gave users a Direct Lake model and watched them switch to DirectQuery within minutes, because they wanted to load an Excel file or change something, and because there was no time hierarchy. They're used to doing what they want in Power BI, and then a Direct Lake model simply feels too rigid.

Microsoft Learn draws a distinction that's missing from the entire discussion, and it determines which limitations actually apply to you. There are two flavours. Direct Lake on OneLake uses data from one or more Fabric sources with Delta tables and has no DirectQuery fallback. Direct Lake on SQL uses a single Fabric source and relies on the SQL analytics endpoint for table and view discovery and for permission checks. That second variant falls back to DirectQuery as soon as the data can't be read directly from a Delta table. For new semantic models, Microsoft recommends Direct Lake on OneLake.

On views, Learn is explicit. If a table in the model is based on a non-materialized SQL view, Direct Lake on SQL falls back to DirectQuery for that table. With Direct Lake on OneLake you can't even create such a table. The advice Learn gives is exactly what the community already recommended: use a lakehouse materialized view, because that does create Delta tables. The alternative is a different storage mode, such as import.

That fallback is controlled by the model property DirectLakeBehavior, which only applies to Direct Lake on SQL. The default is Automatic: if a query doesn't meet the conditions, it silently switches to DirectQuery. Reports keep working, just more slowly. DirectLakeOnly makes the query fail instead, which Microsoft recommends during development to surface problems. DirectQueryOnly forces DirectQuery and exists to measure what fallback costs.

A query only stays in Direct Lake mode when all conditions are met. No row-level security, dynamic data masking or object-level security at the SQL analytics endpoint, no tables based on non-materialized views, no table exceeding the capacity guardrails, and a model that's been reframed after the last change. A single table over a guardrail takes the entire model out of Direct Lake mode.

Those guardrails are concrete and differ per SKU. On F64 it's 5,000 parquet files and 5,000 row groups per table, 1,500 million rows per table and 25 GB of memory. On F2 through F8 it's 1,000 files, 300 million rows and 3 GB. When a guardrail is exceeded, behaviour depends on the flavour: Direct Lake on OneLake fails the refresh, Direct Lake on SQL falls back to DirectQuery with a warning.

To see whether this is happening, Learn provides a diagnostic query. EVALUATE TABLETRAITS() shows a [DirectLakeFallbackInfo] column per table containing the reason. A value of None means the table is running in Direct Lake mode. For tables over the guardrails, OPTIMIZE and VACUUM are the route to try before looking at a larger SKU.

Materialized lake views themselves are declarative. You define them in Spark SQL or PySpark, Fabric materializes the result as a Delta table in the lakehouse and handles the refresh. Fabric picks between incremental, full and skip on its own, though incremental is only possible when change data feed is enabled on the source tables. Dependencies between views are detected automatically and refreshed in the right order, and you can attach data quality rules declaratively with a constraint. Once materialized, such a view behaves like an ordinary lakehouse table, including the same security model.

Finally, something about FUAM itself, because it changes expectations. Fabric Unified Admin Monitoring is explicitly not an official Microsoft product but a solution accelerator. There's no official support, and the authors themselves warn that parts may break, for instance because the capacity metrics extraction depends on an app that can change without notice.

The heart of this discussion isn't missing functionality but a shifted responsibility. In import mode the semantic model is where data takes its final shape, with Power Query as the workbench. In Direct Lake the engine reads the Parquet files sitting in OneLake directly. A view doesn't exist there as a file, so there's nothing to read directly. That's not a forgotten feature, it's the consequence of where the data comes from.

"The limitation is real, but it's mostly an architectural mismatch rather than Direct Lake randomly lacking functionality."

The advice to move to a warehouse works in practice, but the reason usually given for it is wrong. A view in a warehouse falls back to DirectQuery exactly like a view in a lakehouse; that's not where the difference is. The real difference is that a lakehouse SQL analytics endpoint is read-only. You can create views, functions and stored procedures in it, but you can't write data. Materializing there is only possible with Spark. A warehouse does support T-SQL DML, which lets you build a silver or gold layer as a real table using the language you already know. Anyone reading "put it in a warehouse" as "then views will work" is relocating the problem rather than solving it.

That's precisely the gap materialized lake views fill. They give you the declarative SQL of a view with the read behaviour of a table, including refresh, ordering and data quality rules. For someone who only wants to reshape a few columns, that's considerably less work than building a pipeline, and it keeps the transformation where the rest of the team can see it.

Part of the criticism in the discussion is now outdated, and that matters because it changes the trade-off. The complaint that Power Query is out of reach applies to Direct Lake on SQL, which doesn't support composite models. Direct Lake on OneLake does: you can place import tables from other sources alongside your Direct Lake tables, Power Query included. The missing time hierarchy has become flavour dependent too. Auto date/time works in Direct Lake on OneLake and not in Direct Lake on SQL, while a date table you mark yourself works in both cases and is the better design anyway. Calculated columns and calculated tables are available in preview on Direct Lake on OneLake, with calculated columns limited to user context.

The biggest operational risk here isn't a limitation but a default. With DirectLakeBehavior set to Automatic, a model falls back to DirectQuery silently. There's no error, the refresh succeeds and the report keeps working. It just gets slower, and the load moves to the capacity instead of the model's memory. That's a plausible explanation for capacity warnings while filtering a report: not a model that's too heavy, but a model that's no longer running in Direct Lake mode without anyone noticing. So set DirectLakeOnly during development and run TABLETRAITS() before you scale up the capacity.

For a solution like FUAM that deserves extra attention. It's an accelerator without official support, with a semantic model you adopt as-is. Anyone adding their own tables to it is doing so in a model that may change in a future version. A separate layer alongside it, with your own materialized tables, is more durable than modifications inside the shipped model.

That leaves the adoption question, which is a real one. An analyst used to adding an Excel file experiences a thin semantic layer as a loss. That's a consequence of the choice rather than a flaw in it: governance and self service are pulling at the same table here. A workable middle ground is Direct Lake on OneLake with composite models, so the governed part stays fixed while the analyst can put their own import table next to it.