Forum Discussion
Fabric - Copilot optimisation
michaelgambling
You need higher capacity if your semantic model/gold layer is not optimize that you will link with Co Pilot, first of all you need to optimize your gold layer and then test copilot questions,if your gold layer optimize and it will not drain your capcity resources then you are good with F4 capcaity.
Now the question is how to monitor ur capacity useage this can be done via fabric capacity metrics app.
and to go for the higher capcaity will be based on propoer evaluation.If this helps, ✓ Mark as Kudos | Help Others
Proud to be a Super User
I would recommend not considering Copilot as a replacement for a well-designed semantic model. Copilot performs best when the underlying data model is clean, well-documented, and business-friendly annotation.
With reference to your environment (20+ years of legacy SQL schema, limited documentation, and cost-sensitive F4 capacity that is only recommended for light weight workloads), I would recommend :
Create a Gold layer rather than exposing mirrored SQL tables directly to Copilot.
Build business-oriented views and Fabric Warehouse/Lakehouse tables with meaningful names, simplified relationships, and only the columns users need.
This reduces both query complexity and capacity consumption.
Build dedicated semantic models for Copilot. Organize models by business domain (e.g., Sales, Finance, Operations). Add descriptions for tables, columns, measures, and relationships, as Copilot relies heavily on metadata to understand user questions.
Don't rely on mirrored operational databases directly. Mirroring is excellent for data ingestion only, but analytical models should sit on top of curated data, not the operational schema.
Regarding Fabric Data Agents, they're useful for conversational exploration of curated Fabric data, but they won't pay off for a poorly modeled or undocumented database. Focus on improving the data model first.
F4 Capacity Issue:
Regarding your F4 capacity issue, 20–30 Copilot questions draining the capacity isn't surprising. F4 is intended for evaluation and light workloads. Copilot queries often generate multiple DAX queries and consume significant CPU, especially against complex semantic models. Optimizing the model (star schema, fewer relationships, optimized measures, and good metadata) will have a much greater impact than simply increasing capacity.
If this helps, ✓ Mark as Kudos | Help Others
Proud to be a Super User
Hi Murtaza,
Firstly - thank you so much for the detailed response. This is what i was kind of thinking in my head. I just have a question, as per your final paragraph, F4 capacity being non-production standard, would this potentially be an acceptable capacity if i were to treat it as a side, 'copilot only' capacity that is linked to the primary production capacity?
Essentially im fighting a battle in terms of coming up with a workable soloution but keeping it in a cost range that our clients would be willing to pay...
Thanks again for your response!
michaelgambling
You need higher capacity if your semantic model/gold layer is not optimize that you will link with Co Pilot, first of all you need to optimize your gold layer and then test copilot questions,if your gold layer optimize and it will not drain your capcity resources then you are good with F4 capcaity.
Now the question is how to monitor ur capacity useage this can be done via fabric capacity metrics app.
and to go for the higher capcaity will be based on propoer evaluation.If this helps, ✓ Mark as Kudos | Help Others
Proud to be a Super User
