Forum Discussion
Power BI Direct Lake Best Practice
I keep hearing mixed opinions with Direct Lake
For a large Fact Table would you suggest importing DIMS and Direct Lake Fact table?
I keep seeing Direct Query fallback on our DirectLake Fact+Dim approach
Any experience with this pattern on Fabric appreciated.
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.
7 Replies
Hi powerbihelp87,
the best answer to this question is: it depends
I would not really decide on the fact table meta data (large, wide) alone.
For me the following page helped in guide me in my decisions whats the best suitable solution for my task at hand.
Direct Lake vs Import vs Direct Lake+Import | Fabric semantic models (May 2025) - SQLBIHope this helps you as well.
Best regards!
I feel like we are missing a step... directlake performs horribly (takes up all our capacity)
maybe we need to force the direct lake only setting? I noticed certain Dax can cause fall back
i just watched this guys video on YouTube last night! Our architect is strict on no import+direct lake it'll be slower... I don't think that's the case based on research
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.
we 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
any idea how to prevent fall back to direct queries?
all our models fall back?
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.
