Forum Discussion

FabricEnjoyer's avatar
FabricEnjoyer
Regular Visitor
22 days ago
Solved

Optimising Fabric Capacity Usage

Hi all, Due to the recent changes in Fabric capacity metering, I've been spending quite a bit of time trying to optimise our CU consumption. The challenge I've run into is that it's difficult to dis...
data engineering
lakehouse
Notebook
  • v-achippa's avatar
    v-achippa
    22 days ago

    Hi FabricEnjoyer​,

    Thank you for reaching out to Microsoft Fabric Community.

    The CU consumption depends on the workload, so there is no general rule that materializing every sql view into delta tables will reduce capacity usage.

    If the existing sql views are already optimized, I would recommend keeping the current approach rather than moving all the logic to notebooks just to reduce sql consumption. Materializing the views is useful when the same transformation is expensive and reused frequently, but the notebook execution and maintenance also consume fabric capacity.

    Use the Capacity Metrics app to identify whether semantic model refreshes or direct queries from excel and other users are causing most of the consumption before changing the architecture.

    Thanks and regards,
    Anjan Kumar Chippa

Kagiyama_yutaka's avatar
Kagiyama_yutaka
Icon for Skilled Sharer rankSkilled Sharer
19 days ago

Fabric shows CU only per workload and it does not state that SQL views, Delta tables, notebooks or semantic model logic are cheaper. So checking Metrics and splitting refresh and user queries for each workspace is the practical way to see what is actually happening.

Numbers shift between workspaces because views and Delta tables burn CU in different workloads. Views hit SQL CU every time they refresh, and Delta hits Spark CU only when the notebook materialises the table. And in most workspaces, Excel or ODBC ad‑hoc queries mix into SQL CU, so you cannot evaluate any optimisation unless refresh and user queries are separated cleanly in Metrics.