Forum Discussion
MS Fabric : Manage Aggregations Support
1. Does MS Fabric support Manage Aggregations as is available in Power BI?
2. Have created a table in One Lake . Total rows > 100B rows. The current Fabric capacity supports max 3B rows in "Direct Lake" mode. Would like to know if there is "Manage aggregations" option whereby higher grain can be sourced from aggregate table in One lake (Direct lake mode) whereas transaction grain (100B rows) falls back to direct query mode? We dont see the "Manage Aggregation" option in MS Fabric?
3. If "manage aggregation" is not supporte in MS Fabric then how do we handle 100B rows as it will always fallback to "Direct Mode"
Hi Tcs2022 ,
Thanks for reaching out to Microsoft Fabric Community.
Thanks to cengizhanarslan and Murtaza_Ghafoor for the detailed explanations.
Fabric can handle very large data volumes at the storage and compute layer. But, Direct Lake semantic models do not currently support classic Manage Aggregations, and fallback to DirectQuery is expected once table limits are exceeded, even for higher-grain queries.
If aggregation awareness across mixed grains is a hard requirement, a traditional Power BI composite model using Import for aggregates and DirectQuery for detail remains the supported approach.
Regarding Dataflows, they are intended for reusable data preparation and incremental refresh scenarios, and very large initial ingestions are constrained by refresh and capacity limits.
For ingestion at this scale, Fabric scenarios typically rely on Lakehouse ingestion patterns such as pipelines or notebooks, with aggregates materialized separately.
Hope this helps. Please reach out for further assistance.
Thank you.
6 Replies
- cengizhanarslan
Super User
At the moment, Microsoft Fabric does not support the classic Manage Aggregations feature that exists in Power BI (Import + DirectQuery with automatic aggregate hit detection). That capability is tied to the Power BI composite model engine and does not apply to DirectLake–based semantic models.
When a DirectLake table exceeds the supported row limits for the capacity, Fabric will fall back to DirectQuery for that table, and any query touching it will behave as DirectQuery. There is no automatic redirection to an aggregate DirectLake table. In practice, large-scale scenarios like this are handled through modeling and data design, not through aggregation features.
Alternative solutions to think about for you:
-
Restructuring the data so the fact is split into multiple tables or partitions (for example by time or domain) that remain within DirectLake limits. Like FactSales2026, FactSales2025, and so on...
-
Exposing only pre-aggregated Gold tables to the semantic model and keeping the 100B-row detail table out of the model entirely
-
Using a pure DirectQuery model only when transaction-level access is truly required, accepting the performance trade-offs
-
Thanks for the prompt reply. I did consider splitting into multiple facts,however the total rows 100 B /3 B capacity would mean splitting into 33 facts which is not feasible.Business expects reporting at higher & lower grain .hence only agggregtes will not suffice.
Aggregate awareness is aMUST for any BI tool . It is a surprise that MS Fabric doesnt support Manage aggregtions. In the absence of manage aggregtion in msfabric, does it mean, ms fabric is not suitable for reporting large data bolume beyond the capacity limit as fallback will always query in direct mode even if the user creates adhoc report t higher grain.
Can we consider not using msfabric but create a composite model in pbi wherein data is imported at higher grain and lower grain is sourced from one lake thereby implement manage aggregation in the traditional pbi
Can we consider creating datflow to move daily incremental load of 95 M rows to dataflow & implement manage aggregtion.we are avoiding direct query to snowflake(our storage) as it incurs processing cost. However we encountered error during our initial load of 100+B rows. Is there a solution to load 100+ B rows in dataflow as one time load & then incremental load of 95 M per day.
Murtaza_GhafoorUse Case:
The organization needs to deliver BI solution on a 100B+ row dataset with both high-level summaries and transaction-level drill-downs, while avoiding costly DirectQuery to Snowflake.
Proposed Solution:
Enterprise-grade Fabric architecture uses spark notebooks or pipelines to ingest data into a Delta Lakehouse with partitioned, incremental loads. High-value aggregation tables (daily, monthly, and business rollups) are stored as Delta tables and loaded in Import mode, while detailed data is accessed via Direct Lake in a composite semantic model with aggregation awareness and drill-through enabled. This approach avoids Snowflake DirectQuery, leverages OneLake and Fabric compute, and ensures predictable, controlled capacity costs.If this helped, ✓ Mark as Solution | Kudos appreciated
v-veshwara-msftCommunity Support
Hi Tcs2022 ,
Thanks for reaching out to Microsoft Fabric Community.
Thanks to cengizhanarslan and Murtaza_Ghafoor for the detailed explanations.
Fabric can handle very large data volumes at the storage and compute layer. But, Direct Lake semantic models do not currently support classic Manage Aggregations, and fallback to DirectQuery is expected once table limits are exceeded, even for higher-grain queries.
If aggregation awareness across mixed grains is a hard requirement, a traditional Power BI composite model using Import for aggregates and DirectQuery for detail remains the supported approach.
Regarding Dataflows, they are intended for reusable data preparation and incremental refresh scenarios, and very large initial ingestions are constrained by refresh and capacity limits.
For ingestion at this scale, Fabric scenarios typically rely on Lakehouse ingestion patterns such as pipelines or notebooks, with aggregates materialized separately.
Hope this helps. Please reach out for further assistance.
Thank you.- v-veshwara-msft
Hi Tcs2022 ,
Just wanted to check if the response provided was helpful. If further assistance is needed, please reach out.
Thank you.
- v-veshwara-msft
Hi Tcs2022 ,
Just checking in to see if you query is resolved and if any responses were helpful.
Otherwise, feel free to reach out for further assistance.Thank you.
