Forum Discussion
Composite model sluggish, should use Direct Lake?
We recently migrated to Fabric and are implementing a medallion architecture.
Right now, we have Bronze and Silver lakehouses with minimal transformations, ingesting data from our source SQL environment via notebooks.
In the Gold layer, we create a Warehouse where we apply light enrichment before exposing the data.
We refresh the fact tables twice a day, and they grow by roughly 250k rows per day.
Under F8, the solution works, but performance feels slower. Previously, the model was stored using PPU licensing.
The current setup is a composite model: DirectQuery for the fact tables and Dual mode for the dimensions. Given the unexpected performance drop (even after improving the model structure and DAX), I’m wondering whether the missing piece is Direct Lake.
Is it correct to say that the current composite model will remain sluggish because it still relies on DirectQuery rather than Direct Lake? Would you recommend rebuilding the smenatic model using a direct lake approach?
Thanks for any insight
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.
12 Replies
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,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to RicardoTraNa & tharunkumarRTK for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
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.
Thanks 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,
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.
Hi GQ00,
Hope you're doing well! Just following up to see if the response we shared was helpful. If you have any further questions or need clarification, we’re here to assist.
Thanks for being a part of the Microsoft Fabric Community!
Good day everyone,
I appreciate the recommendation of making the model direct lake. I've been reading a lot about it and it might be the best way forward, however I still have some follow up questions
a) is compute consumption comparable with 50 users querying the report? I want to avoid unforeseen compute costs
b) I can appreciate hte model needs to be created in the service; but can be edited in desktop. Yesterday I experienced an issue when using the feature (although I was able to access it in the past), stating that free users did not have access to it. I have a ppu licenses, and the model in a fabric capacity workspace of which I'm admin. Do we know how to bypass it? I'm cautious I may face other unexpected issues when using a new feature.
c) I'm still confused whether direct lake can or can't ingest views to its semantic model
d) Finally, most importnatly, the current composite model includes relationships, measures, hididing columns, calculations groups, roles, hierarchies, dyanmic format strings for measures, conditional formatting in visuals, svg, and visual layout . Is there a way to easily migarte all of this to a model in direct lake? I would really hate to have to redo all that work.
Thanks everyone for their feedback!
