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 UserHi 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) - SQLBI
Hope this helps you as well.
Best regards!
Helper VI 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