Forum Discussion
Post PatronWorkspace domains Vs Cross Functional Projects
Hi fabricpribeiro ,
Great questions, and quite common as Fabric adoption gets past the initial setup for domains!
Let me answer the questions point by point then.
Q1: Is it one lakehouse + one semantic model per project or one semantic model across lakehouses?
The approach with one semantic model per lakehouse should be used if you have projects with distinct ownership, release schedules, and distinct RLS requirements. While sharing a semantic model across three lakehouses may seem neat, in reality, it makes them tightly coupled: any changes in one schema affect reports using another one. If ownerships are really distinct – use dedicated models for them.
Q2: What are criteria to use multiple lakehouses and semantic models in DirectLake mode?
Create separate lakehouses when there is separate data ownership, distinct access controls, or separate refresh/scheduling process for a particular data subset. Don't create a lakehouse just because there are too many projects (as per point one above), split by ownership/access boundaries.
In DirectLake mode, you need one model per lakehouse – the limitation imposed by DirectLake itself. In DirectLake, model is bound to the lakehouse and even the "shortcut" of OneLake refers to only one lakehouse. So splitting projects into several lakehouses will mean having multiple semantic models. Which is fine, you may consider composite models or aggregating Gold in downstream.
Q3: Workspace per project or workspace per group of projects?
As per Microsoft guidance within their Fabric adoption framework, don't attempt to use a workspace per project. There is a limitation of workspaces per tenant and governance overhead increases dramatically. The recommended approach is as follows:
Use a separate workspace for teams/data domains/security boundary where they are different.
Use one common workspace for teams/data domains that share ownership, data stewards, and similar access policies.
So, your example of a financial repository workspace with three projects looks perfectly fine, provided that those three projects share the same data stewardship. Three lakehouses and three models inside one workspace are perfectly valid as well.
Microsoft provides guidance on Fabric workspace governance within the Fabric adoption roadmap, which might be worth checking for further information. Specifically, check out "workspace tenant settings" and "workspace roles" articles.Thank you!
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helpingHi fabricpribeiro ,
Domains are used to organize workspaces into logical groups aligned with business areas, ensuring clear ownership and governance. In Gold, each domain workspace has one lakehouse and one semantic model, promoting reuse and consistency. Q1: For cross‑functional projects, creating one lakehouse and one semantic model per project is adequate when ownership and governance differ; if projects share common dimensions and facts, you may consolidate into a single semantic model to reduce duplication. Q2: Multiple lakehouses are justified when data stewardship, ingestion pipelines, or lifecycles differ, while multiple semantic models are needed when reporting audiences, KPIs, or refresh schedules diverge; consolidation is possible when governance and schema are shared. Q3: New workspaces should only be created when isolation, licensing, or governance boundaries demand it, otherwise grouping related projects into area‑based workspaces with multiple lakehouses avoids workspace sprawl. Microsoft guidance favors domain‑aligned workspaces but allows project workspaces for collaboration when needed. The balance is to keep domains clean and reusable, while grouping projects flexibly to maintain scalability, governance, and manageability.
Thanks,
Sai Teja
Super UserHi fabricpribeiro ,
Great questions, and quite common as Fabric adoption gets past the initial setup for domains!
Let me answer the questions point by point then.
Q1: Is it one lakehouse + one semantic model per project or one semantic model across lakehouses?
The approach with one semantic model per lakehouse should be used if you have projects with distinct ownership, release schedules, and distinct RLS requirements. While sharing a semantic model across three lakehouses may seem neat, in reality, it makes them tightly coupled: any changes in one schema affect reports using another one. If ownerships are really distinct – use dedicated models for them.
Q2: What are criteria to use multiple lakehouses and semantic models in DirectLake mode?
Create separate lakehouses when there is separate data ownership, distinct access controls, or separate refresh/scheduling process for a particular data subset. Don't create a lakehouse just because there are too many projects (as per point one above), split by ownership/access boundaries.
In DirectLake mode, you need one model per lakehouse – the limitation imposed by DirectLake itself. In DirectLake, model is bound to the lakehouse and even the "shortcut" of OneLake refers to only one lakehouse. So splitting projects into several lakehouses will mean having multiple semantic models. Which is fine, you may consider composite models or aggregating Gold in downstream.
Q3: Workspace per project or workspace per group of projects?
As per Microsoft guidance within their Fabric adoption framework, don't attempt to use a workspace per project. There is a limitation of workspaces per tenant and governance overhead increases dramatically. The recommended approach is as follows:
Use a separate workspace for teams/data domains/security boundary where they are different.
Use one common workspace for teams/data domains that share ownership, data stewards, and similar access policies.
So, your example of a financial repository workspace with three projects looks perfectly fine, provided that those three projects share the same data stewardship. Three lakehouses and three models inside one workspace are perfectly valid as well.
Microsoft provides guidance on Fabric workspace governance within the Fabric adoption roadmap, which might be worth checking for further information. Specifically, check out "workspace tenant settings" and "workspace roles" articles.
Proud to be a Super User!
📩 Need more help?
✔️ Don’t forget to Accept as Solution if this guidance worked for you.
💛 Your Like motivates me to keep helping