Guides

Fabric workspace architecture patterns

How you organise workspaces affects who can access what, how you manage capacity costs, how complex deployments get, and how independently teams can work.

Patterns
Six, from Pro only to a domain mesh
Separates
Data engineering, modelling, reporting, capacity and audience
Last reviewed
September 2026

The decision this guide helps make

There is no single correct topology. The right choice depends on team size, governance requirements, and how many distinct groups need to consume the data. What works for one small central team stops working once several teams need different access to the same data.

The six patterns below are ordered by how much they separate. Most are the natural next step once the one before them breaks down, so the useful question is which one your constraints have already pushed you towards. Two sit off that scale. Pro only is a licence position, and it comes before any topology does. Split, Pro reporting moves sideways from Split, to the same two workspaces on a different licence.

The order these are set out in, by how much they separate. Pro only comes before the scale starts, and the two Splits are alternatives at one point on it. Where a pattern sits says nothing about how good it is.

What you are separating

Every pattern below is a different way of drawing boundaries around three things.

  • Data engineering. Pipelines, notebooks, the lakehouse. Where data lands and gets shaped.
  • Modelling. The semantic model, where the business logic lives.
  • Reporting. The reports and dashboards built on that model.

Starter puts all three in one workspace. Domain mesh gives every domain its own set of all three. The patterns in between mostly differ in where the modelling container sits, because that is the one that moves.

Two things decide where it goes.

Capacity. A Direct Lake model has to sit on a Fabric capacity, and on the smaller SKUs its memory allowance is tight: 5 GB on F16 and 10 GB on F32, against 25 GB on F64. Moving the model to an imported one on Pro takes it off the capacity altogether.

Audience. Who builds what. If the same people build the models and the reports, those two can share a workspace. If report authors work on a model somebody else owns, separating them gives each group a boundary of its own.

Choose a pattern

SituationChoose this patternWhy it fits
Reporting is needed, Pro licences exist, and no Fabric capacity has been signed offPro onlyImported models on shared capacity carry real reporting without a capacity
A team of three or four builds the pipelines, models, and reports themselvesStarterNo cross-workspace overhead while you learn your real usage patterns
Engineers and analysts need different access, and reports ship on their own cycleSplit, Direct LakeThe workspace boundary matches the team boundary, so ownership is explicit
A smaller capacity is busy with engineering, and reports are competing with itSplit, Pro reportingAn imported model on Pro takes the report queries off the capacity entirely
Finance, Marketing and Operations each want their own reporting spaceHub and spokeEach team gets its own reporting space and shares one engineering layer
Each domain has its own budget, data team, and delivery prioritiesDomain meshEach domain moves at its own pace without queueing behind a central team

Patterns in detail

Practical next step

Changing topology later means moving items, re-pointing shortcuts and semantic models, and redoing security. It is worth a second opinion before you commit. If you are weighing two of these against real governance and access requirements, an assessment can test the decision against your own data.

Talk it through

Related reading