Forum Discussion
Helper IIIComposite model sluggish, should use Direct Lake?
You can consider testing the performance with Direct Lake mode. There are two different Direct Lake storage modes available, Direct Lake on OneLake and Direct Lake on SQL Analytics endpoint/Warehouse. For better performance I would suggest you to use Direct Lake on OneLake mode for Fact tables and Import mode for Dimension tables.
Please note If your delta tables exeed certain limits and gaurdrails then you will not able to use Direct Lake on OneLake. Please refer the below article to know about those gaurd rails
In those scenarios you can opt for Direct Lake on SQL Analytics endpoint/Warehouse. However, with Direct lake on SQL analytics endpoint, your queries might fall back to direct query, and it will impact your performance again.
I would suggest you to optimize your delta tables and leverage Direct Lake on OneLake to achieve best performance
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-understand-storage
read my articles here: techietips.co.in
Connect on LinkedIn
Did I answer your question? Mark my post as a solution! If I helped you, click on the Thumbs Up to give Kudos.
Proud to be a Super User!
Hi! Yes... the performance drop you’re seeing is very likely due to the composite model still relying on DirectQuery. Even with model and DAX optimizations, DirectQuery typically cannot match the performance of Import or Direct Lake.
Given your data volume and Fabric medallion setup, I would strongly recommend evaluating a Direct Lake semantic model on top of your Gold Lakehouse. In most analytical scenarios like yours, Direct Lake provides performance much closer to Import while avoiding refresh overhead.
Hope that help!Hi GQ00,
For your follow-up questions: Direct Lake compute consumption is generally more predictable than Direct Query since queries use the in-memory engine instead of repeatedly accessing the SQL endpoint. With about 50 concurrent users, F8 capacity is usually sufficient if your semantic model is optimized, but actual usage depends on model size, DAX complexity, and report design. It's a good idea to monitor Capacity Metrics after enabling Direct Lake to understand compute patterns and avoid unexpected costs.
The message about free users not accessing Direct Lake is typically related to how the model is opened, not licensing. If your workspace is Fabric-enabled and you have PPU plus admin access, make sure to open the semantic model from the Service using “Edit in Desktop”, sign in with the right account, and keep Power BI Desktop updated. This usually resolves the issue and isn’t a licensing restriction.
For views, Direct Lake works best with Delta tables and doesn’t rely on views like Warehouse models. Views can be referenced through the SQL analytics endpoint, but this may cause query fallback to Direct Query and impact performance. To ensure consistent results, it’s best practice to materialize key views into Gold Delta tables before exposing them through Direct Lake.
For migration, you don’t typically need to rebuild your semantic model. Most metadata, relationships, measures, calculation groups, hidden columns, hierarchies, RLS roles, dynamic format strings, and report layout, can be reused. Migration is usually a table source rebinding process where you create or switch to a Direct Lake semantic model and reconnect tables to Delta sources using tools like Tabular Editor or TMDL. After rebinding, validate measures and check for fallback scenarios. This lets you move to Direct Lake without losing your modeling work and improves performance.
Thank you.
Helper IIIHi Thanks for your reply.
I followed one of the previous comments and I think I managed to hack my way into a Direct Lake + Import model. Now it is a bit flimsy, in the sense that th eUI doens't really tell you you are in DL, but it is a 10kb model, with lightning fast visuals rendering. https://youtu.be/V4rgxmBQpk0?t=4087
Mind you, fact tables are still from the gold warehouse, whereas Dim are also from the warehouse, but import mode - I believe I can even add views to the model, haven't tried-.
TE allowed me to copy the import tables, measures and relationships via simple ctrl+c ctrl+v - incredible -, however some things did break along the way, such as dynamic format string.
Please note that I wasn't able to refresh the model initially due to RangeStart and RangeEnd parameters, had to remove those, and the partitions & filters, since DL does not have partitions.
Editing the DL semantic model via desktop is still an issue, an apparently I'm not the only one experiencing it, and unfortunately theri work around did not work for me. https://community.fabric.microsoft.com/t5/Desktop/Power-BI-Direct-Lake-model-choosing-edit-in-desktop-not-working/m-p/5115329
Finally, I'm not sure how I can salvage any of the visual content, their position, size, color coding; I'll ponder if this approach is still worth following all things considered.
Having said that I want to take a moment to thanks everyone for their help
Community SupportHi GQ00,
Thank you for the thorough update and for outlining the steps you took. It’s good to see the performance improvement you observed.
From your description, the behavior appears to be expected.
If the fact tables are still sourced from the Gold Warehouse, then the semantic model isn’t functioning as a pure Direct Lake model. Direct Lake operates on Delta tables stored in a Lakehouse (OneLake). When tables are accessed through the Warehouse SQL analytics endpoint, the engine may act like DirectQuery or revert to DirectQuery depending on the query. This explains why publishing the PBIX from Desktop keeps DirectQuery/Dual storage mode.
To fully transition to Direct Lake, you should:
Make sure Gold tables are available as Delta tables in a Lakehouse. If they’re only in the Warehouse, you can copy them into a Lakehouse using a notebook or pipeline.
Create a Direct Lake semantic model from the Lakehouse in the Fabric Service.
Reuse your existing model logic by opening the current model with Tabular Editor or TMDL and rebinding the table sources to the Lakehouse Delta tables instead of the Warehouse endpoint.
This lets you keep your existing model objects, such as measures, relationships, hierarchies, calculation groups, hidden columns, and RLS roles, while benefiting from Direct Lake performance.
For the issues you mentioned:
Direct Lake models don’t use partitions, so incremental refresh parameters and partition filters usually need to be removed.
Dynamic format strings may need minor adjustments after migration, depending on their setup.
The edit behavior in Desktop has been reported by others and may depend on the Desktop version or workspace configuration. Managing the model through Tabular Editor or the Service can be a temporary workaround.
To keep your existing report visuals, layout, and formatting, you generally don’t need to rebuild the report. You can rebind the report file to the new semantic model, preserving the visual layer.
The performance improvement suggests the model is heading in the right direction. The main step left is ensuring the fact tables come from Lakehouse Delta tables so the engine can fully use Direct Lake without fallback.
I hope this clarifies the process.
Thank you.