FinOps Toolkit on Fabric Capacity is slow

[francesco1119]

I have setup the FinOps Toolkit and I'm creating custom Power BI dashboards based on the Cost_Summary.pbix

No, I haven't created Measures or Calculated Columns.

My ADX is running on a Standard_D11_v2

Scale out is set to be Optimized autoscale:

and yesterday while working I've noticed the spikes:

My dashboard is a copy/paste of one of the tabs that you can find in the Cost_Summary and is not loading excessive data (here in the picture I'm only showing Azure Bastion as an example as I don't want to show real data. Imagine this report can ideally load months and years. I have up to 6 years of data) :

The workspace to which I have published this dashboard is linked to a Fabric Capacity F2. And yesterday, at the same time, I saw some throttling. Kinda a lot of throttling:

The User Experience was miserable.
Frankly I was ashamed to share this with my colleagues.

My Questions:

• Where is the bottleneck? (I think it's Fabric, not ADX)
• How to fix it? (Scaling up Fabric or ADX?)
• Capacity: I have monthly export since 2019. 6 years of data. Is that too much?
• Should I move the Workspace from Fabric F2 back to Power BI Premium?

[francesco1119]

Frankly, this is my first custom dashboard and I'm not impressed.

As you can see it's a copy/paste of the Cost_Summary. (Only 1 tab, I removed all other tabs)
It cannot be that slow.

I've faced 300% of Interactive rejection while I was the only one on the dashboards.
It's crazy and it's unusable.
Try to think when I will share this with 20-60 colleagues. It's unusable.

[francesco1119]

I'm using Direct Query. It's the only way to query 6 years of data.

But the problem is not the amount of data. the model is slow even if I query 1 month.
So I can delete all the years and keep only 2025, this will not change the fact that it will be slow if I target just 1 month.

In import mode is faster but it takes up to 2h to refresh and there, yes, you can only query a limited amount of data (2-3 years).

[francesco1119]

Nah, I don't want to go through that pattern.
No hacky modification of the data model. Then when I will have to upgrade the FinOps Hub I will lose everything.

[francesco1119]

@RolandKrummenacher , have you faced this problem?
Should I move away from Fabric?
How can I debug and find if the problem is at ADX level or Fabric level?

It's ironic: with the normal Azure export to CSV and Blob Storage I was able to live 4 years without problems and zero costs.
Now I move to a "modern" solution and suddenly $500/month of ADX and $260/month of Fabric. For dashboards that won't load.

Explain that to a CFO.

[RolandKrummenacher]

Since you are only using Fabric for PowerBI reports: Don't you have a shared PowerBI capacity in your organisation? Why using a dedicated Fabric F2 only for PowerBI reports?

[francesco1119]

Yes.
We are practically saying that PowerBI Capacity is better than Fabric Capacity.
Crazy.

I will tr and I will let you know.

[RolandKrummenacher]

@francesco1119 glad you're going to try the shared Power BI capacity — that should make a noticeable difference since it likely has significantly more compute than a standalone F2.

A few things I want to clarify in case it helps:

Where the bottleneck is: You can check this yourself. Run .show queries in your ADX cluster to see how long the queries take on the ADX side. If they complete in a few seconds, then the bottleneck is Fabric capacity, not ADX. My bet is on Fabric — F2 is the smallest SKU available and has very limited Direct Query throughput. The 300% interactive rejection you're seeing is Fabric telling you it's out of compute. Any Direct Query report on F2 would behave the same way, regardless of FinOps Toolkit.

On the dual-dataset idea: I understand your concern about losing customizations on upgrade, but this would live in your custom report, not in the hub template. It's also not a hack — it's a composite model, which is the standard Power BI pattern Microsoft recommends for exactly this scenario (mixing historical aggregates with recent detail). Worth considering if Direct Query performance alone doesn't meet your needs even on a larger capacity.

On cost: That's fair feedback. The toolkit deploys ADX, but Fabric is not required — especially if you're only using it for Power BI reports. A Power BI capacity (e.g. a shared one your org already has) works just as well, since Fabric capacities and Power BI capacities are the same thing under the hood. That alone would eliminate the $260/month. For ADX, you can reduce cost with reserved instances on both the VM and the markup.

[francesco1119]

I tried to run .show queries but I receive this error:

Query Limits Exceeded

Query execution has exceeded the allowed limits (80DA0003): The results of this query exceed the set limit of 64 MB, so not all records were returned (E_QUERY_RESULT_SET_TOO_LARGE, 0x80DA0003). See https://aka.ms/kustoquerylimits for more information and possible solutions..

 clientRequestId: Kusto.Web.KWE.Query;5812a914-2ffe-472e-81bc-bfab639c4f94;758bdd43-ba6b-45ea-9b3a-8105a744478f

I'm running ADX on Standard_D11_v2.
I have removed Fabric. I'm now fully Power BI Pro license so Fabric cannot be the bottleneck.