Reasons to split into multiple workspaces
• Simplifies cost allocation
• Makes it possible to use separate capacities
• Makes it possible to use separate Git repositories
• Makes it possible to use separate Fabric Deployment Pipelines
• Makes it possible to use separate regions
• Makes it possible to use separate default Spark Environment
• Makes it possible to use separate network security settings
• Makes it possible to use separate workspace identities
• Makes it possible to use separate workspace default settings for specific workloads
• Makes it possible to use separate domains, incl. separate default information protection labels
• Clear ownership
• Clear responsibility for the content in the workspace
• Makes it easier to sync out to a feature workspace, less likelihood of some items with errors blocking the entire Git sync
• SQL Analytics Endpoint sync performance
• Max limit of 300 items for backwards deployment in a Fabric Deployment Pipeline
• Fabric Deployment Pipeline performance may degrade when there are a lot of items in a workspace
• There is a hard limit of 1000 items per workspace, but I guess there may be performance issues related to listing items before you come near that limit
• Makes it possible to grant the Workspace roles: Admins, Member, Contributor and Viewer role without oversharing
Reasons to use as few workspaces as possible
• Don't need to set up the workspace settings multiple times
• Don't need to grant workspace access multiple times
• Fewer API calls when listing workspaces, listing items in workspaces, etc.
• Shorter workspace list
• Fewer Fabric Deployment Pipelines
• Somewhat easier to see item dependencies
• Fewer workspace identities
Other considerations:
• Workspace name (and workspace description?) can be useful for Copilot for content discovery.
From <https://www.reddit.com/r/MicrosoftFabric/comments/1r4gd0p/medallion_architecture_pro_and_cons_of_different/>
First things to consider when splitting:
1 - Business unit access (engineers included). You may have people working on HR data/scripts, but they shouldn’t be able to access finance data/scripts.
2 - Development items vs reporting. Why? Because you can assign different capacities per workspace. For example, F16 for development/scripts and F8 for reporting.
3 - Medallion architecture. One Lakehouse for each layer (bronze, silver, gold). I would recommend taking a look at using a Warehouse for reporting as well. You can copy items from the Lakehouse gold layer to the Warehouse. The important thing is to split the layers. It makes troubleshooting easier.
4 - Databases should be split by schema, not at the higher data lake level. One bronze data lake can contain several schemas, one for each data source.
5 - If you need to share items between workspaces or other data lakes, use shortcuts.
In the long term, you should also think about performance, especially if you want to build a larger data platform.
Each workspace has only one metadata sync service. To avoid a long "waiting line," use separate workspaces so each layer (Bronze/Silver/Gold) gets its own dedicated engine to process changes in parallel.
Packing too many lakehouses into one workspace causes "sync lag." Moving lakehouses to separate workspaces is the only way to scale the system, making sure your latest data shows up in your reports without delay.
Heavy data loading in the Bronze layer could "clog" your Gold dashboards. Keeping them in different workspaces protects your reporting performance from the stress of background data imports.
Automatic metadata discovery tracks changes committed to lakehouses, and is a single instance per Fabric workspace. If you're observing increased latency for changes to sync between lakehouses and the SQL analytics endpoint, it could be due to large number of lakehouses in one workspace. In such a scenario, consider migrating each lakehouse to a separate workspace as this allows automatic metadata discovery to scale.
https://learn.microsoft.com/en-us/fabric/data-warehouse/sql-analytics-endpoint-performance
https://learn.microsoft.com/en-us/fabric/data-warehouse/limitations#limitations-of-the-sql-analytics-endpoint
I wrote this 18 months ago but I’m sure most of the logic still holds up. u/frithjof_v has laid out a more comprehensive pros and cons list, but I think the main pro is around governance and ownership. While there are more pros to separating than not, it’s worth asking whether you need any of those pros rather than assuming you do.
https://blog.alistoops.com/microsoft-fabric-workspace-structure-and-medallion-architecture/