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.
powerbihelp87we are using direct lake
- rls- yes
- power query- no since it's DL that option isn't available
- no calculated column since it's DL
- one to many joins no bidirectional
I haven't seen any benefit besides throwing money at fabric with direct lake honestly. It's slow lags but it could be something. We are doing.
we met with our Microsoft rep but honestly no real feedback
- powerbihelp87
any idea how to prevent fall back to direct queries?
all our models fall back?
v-hashadapuCommunity Support
Hi powerbihelp87 , Thank you for reaching out to the Microsoft Community Forum.
In Microsoft Fabric Direct Lake, fallback behaviour is not controlled by a user-configurable setting. If a query or model feature cannot be evaluated against the in-memory data, the engine automatically routes execution to the SQL endpoint. In your case, since all models are falling back, this indicates a consistent model level constraint rather than a configuration gap.
Based on what you’ve confirmed, RLS is the most likely cause, if it cannot be resolved using only dimension-level filters, it will trigger fallback for the entire query. Temporarily disable RLS and retest, if fallback stops, you’ll need to redesign the RLS logic to be compatible with Direct Lake evaluation.
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.