Forum Discussion
Post PatronWorkspace domains Vs Cross Functional Projects
Dears,
In our fabric architecture we have the following layers : Raw, Bronze, Silver, Gold
For raw, bronze and Silver, there is no division by domain. We only get into data mesh approach once we arrive to Gold
In Gold, we have one workspace per domain.
Inside each gold workspace we have one, and only one, lakehouse and a single semantic model (using onelake direct lake)
This works well when we speak about data related with domains like (master data, finance, claims, etc...)
Each Domain grabs the infromation they wish from Silver (via shorcut), and create their dimensions and fact tables , which they own and allow other domains to consume, hence promoting re-usabibility
So far, so good
But this was the foundation, now we are getting into the era where projects want to get in , into fabric.
We have create for example a new workspace now, which is not a real domain, its called Financial repository, inside it, we are thinking in having 3 lakehouses, one per each project. And probably, we will have one semantic model per each of this lakehouses, meaning, 3 semantic models
So, for project workspaces (or if you prefer , for cross domain workspaces) we will probably have more than one lakehouse as opposite to the domains, and probably, one semantic model per each lakehouse , using the onelake direct lake mode
I am describing this scenario to hear your opion about this architecture shift
Q1 : For this workspace in gold, we are creating one lakehouse and one semantic model per each project as they have different ownership. Do you think its adequaded? or for example, would you create 3 lakehouses but only one semantic model?
Q2 : What are the criteria that you are using to decide when to create more than one lakehouse per workspace? and which criteria are you using to create more than one semantic model per workspace knowing that we wish to use the onelake direct lake mode?
Q3: I was also considering creating one workspace per each project to maint exaclty the same architecture, the problem is that if I do it, I may end up with hundreds of worskpaces .. hence I am trying to group them by area. What are the criteria that you are using to decide when to create new workspaces Vs when to use existing ones and add an additional item (lakehouse) ? Do we have any guidance from Microsoft on this?
Thanks a lot,
Pedro
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
4 Replies
MJParikhSuper User
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 helping
SaiTejaTalasilaHi 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
v-veshwara-msftCommunity Support
Hi fabricpribeiro ,
Thanks for reaching out to Microsoft Fabric Community.Just wanted to check if the response provided by MJParikh was helpful. If further assistance is needed, please reach out.
Thank you.- v-veshwara-msft
Hi fabricpribeiro ,
Just checking in to see if your query is resolved and if any responses were helpful.
Otherwise, feel free to reach out for further assistance.Thank you.