Architecture decision : Separate workspaces

Dear all,

I'd like to share my thinking on the proposed workspace separation and ask for your views before I formalise the pros and cons document.

**Context**

We currently have a raw zone shared by both the Global team and the dedicated UK team. There are no data sovereignty constraints, so all data can land in the same capacity and workspace.

Our architecture has four layers: Raw, Bronze, Silver and Gold. Gold already has one workspace per domain and is not the subject of this message. The focus here is on Raw, Bronze and Silver, which were designed with one workspace per environment (i.e. a single Raw workspace, a single Bronze workspace and a single Silver workspace, each one with a single lakehouse).

I've been told the company would like to split each of these into two workspaces — one for Global and one for UK — per environmen (with its own lakehouse inside) , with the goal of enabling an independent development approach (e.g. a Raw workspace for UK and a Raw workspace for Global, and likewise for the other two layers).

I've been asked to produce a pros and cons document on this separation, bearing in mind that development is about to start and there is not yet technical debt at this stage n relation to this.

**My position**

I see no issue with the separation for Bronze and Silver — in fact, I would encourage it, so the two teams are fully independent in terms of both security and development.

However, I would not recommend separating Raw, for the reasons below.

**Why Raw should remain a single workspace**

Some of our sources impose hard constraints on where they can land:

- For CDC sources (SQL Server on-premises) and for SQL Server MI using Fabric mirroring in CDC mode (where the update policy is 2022), I believe we can have one CDC feed per workspace — meaning two different CDC feeds for the same database, one per workspace. I'm not yet certain of this, however; it may only be possible for the same database, in the same environment, if each feed captures different tables. I will verify.

- What is definitely not possible: SQL MI Fabric mirroring (for instances with update policy 2025 or above) and Fabric Dataverse direct link both restrict a given source environment to a single target workspace. Splitting Raw would therefore break, or at least severely complicate, these ingestion patterns. So I would need to create a "shared" workspace for those and work with onelake shorcuts to both (one for global and another for Uk) per schema / table

**Why Bronze and Silver separation works**

For Bronze and Silver, separation seems to me the right call — both for permissions and for development — because:

- The workspace is the only true development isolation boundary. Anyone with the Contributor, Member or Admin role in a workspace can read and modify every item and every schema within it, and development requires at least Contributor. Two teams developing in the same workspace can therefore never be isolated from each other, regardless of any data-level security applied.

- Schema-level security exists, but only for readers. OneLake security (generally available since May 2026) supports roles at schema, folder and table level in schema-enabled lakehouses, including row- and column-level security, enforced across all Fabric engines. The SQL analytics endpoint additionally supports classic T-SQL GRANT at schema level. However, neither mechanism constrains workspace Contributors. A schema-per-team design inside shared workspaces would therefore not deliver the requested development isolation — it would only segment read access for consumers.

**Proposed direction**

In summary, my recommendation would be: split Bronze and Silver per team, keep Raw as a single shared workspace per environment.

I'd appreciate your views on this before I finalise the document.

Thanks a lot,

Pedro