Forum Discussion
Best Practice for Building and Sharing Semantic Models in Microsoft Fabric
Hi Manoshi
In Fabric, for best performance and cost efficiency, use directlake (anything else will require larger capacities to run).
Add all of your calculated columns using notebooks before adding tables to the warehouse (bronze, silver, gold architecture), then build semantic models using star/snowflake schemas.
With directlake, having multiple semantic models that serve similar purposes isn't such a problem, as the warehouse bares the brunt of the CU requirements, and the warehouse is the one source of truth so data isn't duplicated or manipulated.
Your devs will not be able to add calculated columns in the model when using directlake, so you will need to add all columns for them, which will require extra effort on your part (and dropping tables if evolving schemas aren't enabled), but it will improve governance. Once your notebooks are templated, this isn't much work.
On workspaces, it's going to be helpful to have them stored together with the warehouse for central administration, and in a capacity emergency, the workspace can be moved to a 'recovery' capacity. Security would need to be applied at the item level rather than workspace in this scenario.
--------------------------------
I hope this helps, please give kudos and mark as solved if it does!
Connect with me on LinkedIn.
Subscribe to my YouTube channel for Fabric/Power Platform related content!
wardy912 Thanks a lot for the detailed explanation, it’s really helpful.
I just wanted to clarify one thing: if I apply row level security (RLS) on the warehouse, will the connection fall back to DirectQuery as mentioned in the Microsoft documentation? If so, would we still get the expected performance benefits of DirectLake, or would there be a noticeable impact?
Appreciate your insights on this.