Forum Discussion
Best Practice for Building and Sharing Semantic Models in Microsoft Fabric
Hi everyone,
I’m looking for guidance on best practices for designing my architecture in Microsoft Fabric. My main goal is to create a semantic model using Fabric Warehouse data, build reports on top of it, and also share the semantic model with other developers so they can create their own reports.
I’m a bit uncertain about what connection mode I should be using — Import, DirectQuery, DirectLake, Hybrid Tables, or Dual mode — to achieve the best balance of performance, flexibility, and maintainability.
Here’s what I’ve done so far:
I created a semantic model using the Warehouse SQL endpoint, combining DirectQuery + Import + Dual tables, and built relationships on top of it.
Then, I created another semantic model based on the first one, where I defined measures, calculated columns, and calculated tables, and used it to build my reports.
Both the Warehouse and semantic models are hosted in the same Fabric workspace.
I have also published both semantic models and reports to a Power BI Pro workspace.
Now I’d like to confirm if this approach aligns with best practices, or if I should redesign the setup from scratch.
Could someone please advise:
Which connection mode (Import, DirectQuery, DirectLake, Hybrid, or Dual) is most suitable for my scenario?
Is my current two-layer semantic model setup advisable, or should I simplify it?
What’s the recommended architecture for sharing a semantic model with multiple report developers in Fabric?
Any insights, best practices, or examples would be greatly appreciated!
7 Replies
Murtaza_GhafoorSuper User
Best Practices Summary
Use DirectLake for Fabric data sources.
Maintain one unified semantic model.
Share the model using Build permissions.
Separate data and report workspaces.
Certify the model for team-wide reuse.
Avoid chained semantic models (one model feeding another).
Avoid unnecessary refresh cycles — DirectLake syncs automatically.
KevinChantIn part it depends on your ambitions. From a performance perspective Direct Lake is the best mode to aim for.
- tayloramy
As others have mentioned, it really depends on what your goals are.
Import mode is the best performance, but has memory limitations. DirectLake is the best balance between performance, maintenance, and being able to work with large datasets.
I would avoid direct query against the SQL endpoint, that just adds a layer of latency that DirectLake doesn't have.
- wardy912
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.
v-aatheequeCommunity Support
Hi Manoshi
Just checking in to see if the previous response helped resolve your issue. If not, feel free to share your questions and we’ll be glad to assist.
