Forum Discussion
Helper VPower BI Direct Lake Best Practice
When you Import dims and Direct Lake the fact, Power BI handles the join at query time using the framed fact data against the in-memory dim data. This combination is generally faster than pure Direct Lake on both because the dim lookups do not go through the SQL endpoint at all.
The most common causes on a Direct Lake fact table are calculated columns on the fact table, Power Query transformations applied to the fact table, relationships set to bidirectional cross-filter, or RLS rules that cannot be evaluated via framing. Check each of these on your fact table first, any one of them forces the whole model into fallback.
Super UserWhen you Import dims and Direct Lake the fact, Power BI handles the join at query time using the framed fact data against the in-memory dim data. This combination is generally faster than pure Direct Lake on both because the dim lookups do not go through the SQL endpoint at all.
The most common causes on a Direct Lake fact table are calculated columns on the fact table, Power Query transformations applied to the fact table, relationships set to bidirectional cross-filter, or RLS rules that cannot be evaluated via framing. Check each of these on your fact table first, any one of them forces the whole model into fallback.
You could try setting the semantic model to Direct Lake only instead of allowing DirectQuery fallback. While it won't automatically tell you the root cause, it prevents silent fallback. If a query can't execute in Direct Lake, it will fail instead, making it easier to identify the affected visual or query and investigate the underlying unsupported feature or model design.