Forum Discussion
Optimising Fabric Capacity Usage
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
Super UserI would suggest if you opt for medallion architecture
Bronze → Silver → Gold Delta → Semantic Model → Power BI
Please don’t optimize SQL Endpoint consumption in isolation—compare the total CU consumption across the complete workload.
- Keep SQL Views when the logic is simple and inexpensive.
- Materialize into Delta/Gold tables when the transformation is expensive and reused frequently.
- Keep reporting-specific calculations in the semantic model (measures, time intelligence, etc.).
- Moving transformations into Power BI may reduce Fabric CU, but it can increase refresh time and duplicate business logic.
- Separate semantic model refreshes from direct SQL/Excel queries when benchmarking, because user activity can significantly distort the results.
For your Fabric architecture, a good pattern is medallion architecture
Bronze → Silver → Gold Delta → Semantic Model → Power BI
with lightweight SQL views where needed.
The best approach should be determined by measured total CU + refresh performance, rather than assuming Delta tables are always cheaper than SQL views.
If this helps, ✓ Mark as Kudos | Help Other