Workspace Architecture

Hi tim_goodsell 

I have used this approach and works pretty well 

main benefits you will have with approahc:

Keeping code seperate from the data workspaces has been really helpfull. Main benifits I’ve seen so far:
Access is way easier to manage - engineers dont need direct access to prod lakehouses and business users consuming gold data dont need to see all the notebook code. Makes permissons much cleaner.

Capacity isolation is a big one - data engineering jobs cant impact reporting performace anymore since there on diffrent capacities. Before we had issues with noisy neighbours.

CI/CD just works better with this setup - deployment piplines need seperate workspaces anyway so it fits naturally.

We use OneLake shortcuts to connect everthing across workspaces without duplicating data which is nice.

Hola  tim_goodsell ,

Your proposed structure is a good starting point, but here's how I would personally approach it.

One workspace = one complete environment

Rather than splitting workspaces by medallion layer, I would group by environment, with the full medallion architecture living inside each workspace:

[project]-dev    → Bronze + Silver + Gold + Code (all together)
[project]-test   → Bronze + Silver + Gold + Code (all together)
[project]-prod   → Bronze + Silver + Gold + Code (all together)

This is the cleanest structure for environment promotion — Fabric Deployment Pipelines map perfectly to this, one stage per workspace, promoting everything in one go from dev → test → prod in a traceable and controlled way.

The alternative of "one workspace per medallion layer" (a Bronze workspace, a Silver workspace, a Gold workspace) multiplies the number of workspaces by the number of environments — you end up with 9 workspaces for a 3-layer x 3-environment project, which makes deployment management significantly more complex.

Inside each workspace, I would use folders to segment visually by type — for example:

📁 code        → Notebooks, Dataflows
📁 storage     → Lakehouses (Bronze, Silver, Gold)
📁 pipelines   → Orchestration pipelines
📁 semantic    → Semantic Models, Reports

On the number of Lakehouses: 3 is my current rule of thumb — but this is changing

I currently use 3 lakehouses as a general rule (one per medallion layer), but something Microsoft has recently released changes the equation significantly: Materialized Lake Views (MLV).

The SQL syntax is declarative . Once created, Fabric computes the initial results and stores them, and the MLV is available to any workload in Fabric just like a regular Delta table. Microsoft Fabric

This means you can technically implement the entire medallion architecture inside a single lakehouse with distinct schemas (bronze / silver / gold as schemas, not as separate lakehouses), and MLVs propagate changes automatically between layers. Worth noting: cross-lakehouse lineage and execution are currently not available for materialized lake views  which is actually an argument in favour of consolidating into a single lakehouse if you're betting on MLVs.The combination that I think should drive new developments: MLV + Change Data Feed

My personal recommendation for new developments

• One workspace per environment with Deployment Pipelines for promotion
• Folders inside the workspace to segment code, storage, and pipelines
• A single schema-enabled lakehouse + MLV + CDF for medallion logic, rather than 3 separate lakehouses
• Reserve a Gold Data Warehouse only if the team needs heavy T-SQL or very granular RBAC

The MLV + CDF + schemas combination is, in my opinion, where new Fabric developments should be heading. It's declarative, drastically reduces orchestration code, and incremental refresh makes it viable in production.

If my answer helped you, I would really appreciate a like and if you could mark it as the accepted solution. This helps other community members and also motivates me to keep contributing. Thanks a lot!

Hi tim_goodsell, it also depends...

In Fabric, workspaces act as the main boundary for security and isolation between data and workloads. If you need to keep your code and pipelines separate from your landing, bronze, and silver lakehouses for security purposes, it's best to use different workspaces. Otherwise, simplify by keeping everything in a single workspace.

For instance, if your data team is small — just two people handling data flow — or your process doesn't require much compute capacity, there's no need to create several workspaces or use multiple Fabric capacities. All team members will need access to every workspace anyway, so splitting them up won't offer any real advantages.

For example, when your team is small, I suggest having two workspaces per environment: one dedicated to managing the data flow (covering landing, bronze, and silver layers), and another for self-service users or analysts who shouldn't be involved with data flow tasks reporting on the gold layer. Depending on your reporting needs, you can assign a separate Fabric capacity to this second workspace to distinguish between compute used for data flow and that used for reporting.

If your team consists of several engineers, scientists, analysts, and self-service users, it is beneficial to divide the various stages into multiple workspaces and use multiple capacities. This approach allows each user role to access data in the appropriate stage of the data flow. Data scientists might want to have access to the silver layer data, but do not need to access landing and bronze. Analysts and self-service users only need access to the gold layer data.

Hope this helps. If so, please give kudos 👍 and mark as Accepted Solution ✔️ to help others.