Composite model sluggish, should use Direct Lake?

GQ00 

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.

https://www.sqlbi.com/blog/marco/2025/05/13/direct-lake-vs-import-vs-direct-lakeimport-fabric-semant...

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 

https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements

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.