Forum Discussion
Fabric Semantic Model Vs SSAS Tabular Cube
Hi ,
Report which were working well (less than a second) to load with data source as tabular SSAS cube is taking more when data source has been now moved Fabric Semantic model on Direct lake/Direct Query mode.
Will my PBI Reports work as effectivitly as they used to work on SSAS Cube with live connection? as the data was preaggregated?
is there possibility of using the Fabric SM as live connection, with data being preaggregated?
If your SSAS was a "standard import mode model" you're doing a huge jump moving to Fabric DL.
In import mode you've all the data processed and compressed at processing time and then you mount reports in live connection on top of if it.
in Fabric Direct Lake, data resides in Warehouses or Lakehouses as Delta Tables (Parquet files) and the needed data are paged into memory when requested by users. Columns have a temperature and Fabric can decide to page them out. the time to load data into memory affects the query/report time.
according to the capacity size you can experience also performance degradation when the engine is not able to use Direct Lake and switch to Direct Query over SQL endpoint (this process is know as Fallback Direct Lake overview - Microsoft Fabric | Microsoft Learn).
When fallback happens you're basically going to the slowest storage mode automatically and your queries may be affected.I strongly suggest to switch to Import if you have no real reasons to use Direct Lake. If your capacity is correctly sized your performance would be similar to SSAS.
I suggest to double check your capacity is not overloaded that would cause queries (interactive operations) to be throttled even if DL is happening.
I suggest to disable auto fallback if you want to stay direct lake to clearly catch what is happening behind the scenes.
4 Replies
Hi Anusha66 ,
Thank you for engaging with the Microsoft Fabric Community. This situation is quite common when transitioning from SSAS Tabular to Fabric Semantic Models.
With SSAS Tabular (Live Connection), data is preaggregated and stored in memory using the VertiPaq engine, resulting in very fast report interactions. However, when using a Fabric Semantic Model with Direct Lake or DirectQuery, Power BI retrieves data directly from OneLake or the source system. Because the data is not fully cached in memory, performance can be slower, especially for complex visuals or large datasets.
To improve performance and achieve results closer to your experience with SSAS, you might consider the following
1. Prefer Direct Lake over DirectQuery, direct Lake reads parquet files from OneLake with lower latency.
2. Use aggregation tables or hybrid tables, these can cache commonly used summaries in memory, speeding up queries.
3. Optimizing relationships, cardinality, and DAX measures can enhance Direct Lake performance.
Helful Reference: User-defined aggregations - Power BI | Microsoft LearnRegards,
Yugandhar.If your SSAS was a "standard import mode model" you're doing a huge jump moving to Fabric DL.
In import mode you've all the data processed and compressed at processing time and then you mount reports in live connection on top of if it.
in Fabric Direct Lake, data resides in Warehouses or Lakehouses as Delta Tables (Parquet files) and the needed data are paged into memory when requested by users. Columns have a temperature and Fabric can decide to page them out. the time to load data into memory affects the query/report time.
according to the capacity size you can experience also performance degradation when the engine is not able to use Direct Lake and switch to Direct Query over SQL endpoint (this process is know as Fallback Direct Lake overview - Microsoft Fabric | Microsoft Learn).
When fallback happens you're basically going to the slowest storage mode automatically and your queries may be affected.I strongly suggest to switch to Import if you have no real reasons to use Direct Lake. If your capacity is correctly sized your performance would be similar to SSAS.
I suggest to double check your capacity is not overloaded that would cause queries (interactive operations) to be throttled even if DL is happening.
I suggest to disable auto fallback if you want to stay direct lake to clearly catch what is happening behind the scenes.
Hi Anusha66 ,
May I know if your issue has been resolved, or if you still need any additional details? Please let us know if there’s anything else we can help with.
Thank you.Hi Anusha66 ,
Could you please let us know whether your issue has been resolved or if you are still encountering any difficulties? Your feedback is important to the community and may assist others with similar concerns.
Thank You.
