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.
Helper Vwe 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