[[About|Andrew Boerger]] | March 26, 2026 > [!tip] TL;DR > Splitting one Fabric project across multiple workspaces makes sense when you need real separation of ownership, security, capacity, or workspace-level features. Otherwise, extra workspaces can create more friction than value in lineage, monitoring, CI/CD, navigation, and day-to-day development. Current Fabric capabilities favor keeping a centrally managed solution together unless requirements force it apart. In any scientific discipline, the phenomenon of [lumpers and splitters](https://en.wikipedia.org/wiki/Lumpers_and_splitters) is well known. Any time there are *things* to be organized there is a seemingly inevitable phenomenon of two factions, the "lumpers" and the "splitters." Lumpers favor of grouping *things* together based on similarities, versus splitters who favor creating more categories and groups to suit precise definitions. The same instinct appears in every Fabric architecture slide. Do we have one workspace per project? Per domain? Per medallion layer? Per project, domain, layer, function, and development environment? :) For large organizations with mature delivery practices, splitting brings organization and control. For a small to mid-sized central platform team, though, the splitting impulse can create more complexity than the problem actually demands. And why exactly do we need this complexity? What is the reason we might incorporate multiple workspace into our Fabric solutions? Many of the very best [frameworks](https://github.com/edkreuk/FMD_FRAMEWORK) and [enterprise-ready Fabric implementations](https://blog.fabric.microsoft.com/en-us/blog/optimizing-for-ci-cd-in-microsoft-fabric?ft=All) choose to have separate workspaces for ingestion, transformation, orchestration, modelling, and so-on. There are real reasons to separate. But if you're on a smaller data team which is building out a central Fabric platform or reporting "hub" for your organization, allow me to lay out the case for fewer total workspaces. The more I work with Fabric, the more I realize that the platform itself begins to fight you when you split a single project/solution across multiple workspaces. Note that I'm not talking about environments for application lifecycle management (i.e. dev/test/prod) but rather a single solution divided among multiple workspaces within the same environment. ## Reasons to consolidate 1. Many Fabric items still have cross-workspace limitations. If you reference a Variable Library from your notebook, that Variable Library needs to be in the same workspace. T-SQL notebooks need to be in the same workspace as the storage artifact. 2. Many features are scoped at the workspace level, such as OneLake diagnostics and encryption with CMK. 3. Every new workspace adds a bit of mental friction. If we divide a project into five workspaces and three environments, we're already bouncing around fifteen workspaces for that single project. This concentration tax adds up quickly during the everyday workflow of navigating, developing, and monitoring your project. 4. Workspace lineage may not give you the full story of an artifact's relationships. You will need to select the artifact and display cross-workspace lineage. 5. Task flows become less useful, as task-flows are created within a single workspace. You will no longer be able to document and visualize the scope of your Fabric project in a single task flow. 6. Workspace monitoring becomes more expensive and less centralized. The “workspace monitoring” feature must now be enabled in multiple workspaces, each sending a portion of your solution’s telemetry to different Eventhouses in each workspace. 7. CI/CD is more complex. You must now manage the deployment of multiple workspaces, using either the Git APIs, Fabric Deployment Pipelines, or the `fabric-cicd` library. You must carefully consider the dependencies between workspaces (and ideally keep those dependencies one-way only). 8. There is no way to easily group or associate workspaces in the navigation pane. It may quickly become cumbersome to navigate `[number of projects] x [number of workspaces per project] x [number of environments per project]`. In short, a multi-workspace strategy is only as strong as the weakest cross-workspace experience among the Fabric items you depend on. Now, if we are choosing to break or reduce some functionality by dividing our solution across many workspaces, we should be gaining something in return, right? ## Reasons to split 1. We could spread artifacts over multiple workspaces to exceed the per-workspace limit of 1000 artifacts. 2. Fabric Deployment Pipeline performance improves with fewer artifacts per-workspace. 3. We could divide workspaces among multiple capacities for workload isolation. 4. We could introduce different workspace-level security roles for users, groups, and workspace identities. 5. We could hand off ownership and development of domains to different technical or business teams. If this is an explicit part of your business strategy, then multiple workspaces may be a thoughtful way to future-proof your architecture. 6. We could introduce Private Link in specific workspaces and leave it disabled in others. 7. In theory, SQL Endpoint sync performance could be improved since there is one metadata sync service per workspace. 8. Blast radius of serious bugs and deployment mistakes could be limited. ## Considerations for small teams For a small central team maintaining a typical Fabric solution (ingestion, storage, transformation, modelling), fewer workspaces makes a lot of sense. You should consider keeping one workspace per solution per environment unless you have concrete boundaries you need to enforce by dividing the project workspaces. - You should be using metadata driven approaches which encourage the use of central auditing and reusable templates over bespoke notebooks for each process. This naturally limits the amount of artifacts you need, even for very large enterprise solutions. The 1000 artifact limit per-workspace should not be relevant. - If your team is using Fabric Deployment Pipelines, then you can deploy your entire solution together in a single step, with dependencies and autobinding (mostly) handled by the pipeline + intelligent use of deployment rules and variable libraries. No need to create multiple interdependent pipelines for a single project. - Typically only the project team will be managing the project workspace, so we don't lose anything in terms of workspace permissions. We can still grant read access to individual artifacts, particularly our SQL endpoints and semantic models. Soon we will also be able to distribute those artifacts selectively via multiple dedicated Org Apps in a single workspace, once org apps reach GA. Until then we may need to keep individual reporting workspaces corresponding to the number of Workspace Apps that we expect to publish to the business. - As of March 2026, we can now selectively branch out only specific items into our feature branch. We don't need to branch out hundreds of unrelated and unneeded items (especially storage) from our single workspace to begin feature development. Fabric's ALM capabilities are increasingly removing the old reasons we used to split workspaces. - If data mesh and multiple technical/data teams are not an explicit part of your business strategy, then don't make your solution more complicated "just in case" you need to carve it up to handoff ownership someday. Have some awareness of the maturity level and technical ability across your organization. For many SMEs, if you have a single technically mature platform team serving business analysts in multiple domains, **you are already doing great**. - For a small central team, blast-radius reduction is outweighed by the extra overhead, and complexity of multiple workspaces for the same project. And this extra complexity *can itself become a source of mistakes and bugs* during development. ## To conclude A useful razor when thinking about workspace architecture: "If I split this solution into multiple workspaces, what goal am I achieving that I could not achieve any other way?" If the answer is something vague like "future-proofing," "clean layers," or "it feels more mature," then you might be overcomplicating. If you have a concrete justification due to multiple development teams, truly independent projects, different workspace-level feature needs, CI/CD, and capacity isolation - then consider splitting accordingly. But choose your default approach carefully...