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.
Community SupportHi 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.
GQ00Thanks for all your help.
This is a solution, thank you.
If you have it handy, would you mind sharing more info on the rebinding process to migrate this model to Direct Lake?
Thank you,
- v-sgandrathi
Hi GQ00,
When migrating a semantic model to Direct Lake, the main goal is to reuse your existing model metadata and update the table source bindings so they reference Delta tables in your Lakehouse. Start by making sure your Gold layer tables are available as Delta tables in the Lakehouse, since Direct Lake uses Delta tables stored in OneLake. Then, create a Direct Lake semantic model from the Lakehouse in your Fabric workspace for reference. Open your current semantic model in Tabular Editor (or via TMDL if using source control) and update each table's source definition to point to the Lakehouse Delta table instead of the previous Warehouse or SQL endpoint used for DirectQuery. Once the bindings are updated, deploy the model back to the workspace. Your model objects like measures, relationships, calculation groups, hierarchies, hidden columns, RLS roles, and dynamic format strings will stay the same. After deployment, validate by refreshing metadata and testing reports, and check for Direct Lake fallback scenarios and monitor performance with the Capacity Metrics app or Performance Analyzer. This process lets you migrate to Direct Lake without rebuilding your semantic model or report logic, while benefiting from better performance.
Thank you
Sahasra.- GQ00
Hi,
Thanks for your reply, could you aid me in following the steps you've listed?
'Then, create a Direct Lake semantic model from the Lakehouse in your Fabric workspace for reference. - Created in the workspace
Open your current semantic model in Tabular Editor (or via TMDL if using source control) and update each table's source definition to point to the Lakehouse Delta table instead of the previous Warehouse or SQL endpoint used for DirectQuery. - I don't follow. The tables in desktop model are tables in gold warehouse. Can you please expand on this?
Once the bindings are updated, deploy the model back to the workspace.' - Publishing from desktop does not create a DQ model, it maintains DQ and Import storage mode.
Firstly, my gold tables are in a warehouse. Currently I have a desktop PBIX with DQ store mode on fact. dual on Dim.