This page defines the capacity-level configuration options that must be evaluated for our Microsoft Fabric platform, with a focus on:
Our target operating model uses Fabric primarily as a data storage and exposure platform based on Lakehouse and Warehouse, serving both BI consumption and external data exposure. |
Fabric capacity configuration is a platform governance topic, not only an infrastructure topic.
The primary control for protecting Data Platform Core is capacity isolation.
Shared capacity between Data Platform Core and Domain production creates shared operational risk.
A dedicated capacity for Data Platform Core is the recommended baseline for this architecture.
Version | Date | Description | Contributor |
V0.1 |
| Initial document | COLOMBANI Théo |
V0.2 |
| Updated with schema proposal and checklist | COLOMBANI Théo |
This page defines the main capacity design decisions for our Microsoft Fabric platform.
The objective is to ensure:
In our architecture, Microsoft Fabric is primarily used as a storage and exposure platform, based on Lakehouse and Warehouse, for both BI consumption and external data exposure.
The Data Platform Core workspace must remain operational independently from Domain workspaces, including when Domain workloads generate higher or less predictable compute consumption.
| Decision area | Use this approach when | Recommended decision |
|---|---|---|
| Dedicated capacity for Data Platform Core | bronze and silver are production-critical; downstream BI or external exposure depends on them; Domain workloads are more variable than Core workloads; Core continuity is a priority | assign Data Platform Core to a dedicated capacity |
| Separate Domain production capacity | multiple Domain workspaces coexist; Domain workloads may create contention; business-facing usage is less predictable; Domain growth should not affect Core operations | assign Domain production to a separate capacity |
| Separate non-production capacity | development and testing are active; experimentation may generate compute spikes; production stability must be protected from non-production activity | keep non-production on a separate capacity |
| Architecture review required | Core and Domain are still planned on the same capacity; workspace reassignment is not tightly governed; production and non-production still share capacity; capacity sizing issues become recurrent | escalate to architecture review |
| Setting | Data Platform Core | Domain Production | Non-Production | Recommendation |
|---|---|---|---|---|
| Dedicated capacity | Yes | Preferred | Separate | Mandatory for Data Platform Core |
| Shared with Data Platform Core | No | No | No | Not allowed |
| Workspace reassignment rights | Very restricted | Restricted | Controlled | Govern centrally |
| Monitoring | Mandatory | Mandatory | Recommended | Standard operating baseline |
| DR assessment | Mandatory | Case by case | Not priority | Explicit decision required |
| Spark governance | Case by case | Case by case | Flexible | Only where relevant |
| Scaling review cadence | Regular | Regular | Periodic | Metrics-driven |
Capacity design must be driven by isolation first, then by optimization.
In our context, the main purpose of capacity governance is not only to size compute correctly. It is primarily to:
For our platform, capacity is an architecture boundary, not only a billing or administration object.
Used only for:
Used for:
Used for:
Do not place Data Platform Core production and Domain production on the same capacity if Data Platform Core must remain operational independently.
A shared capacity creates a shared risk envelope. Even if workspaces are logically separated, they still depend on the same underlying capacity behavior.
The assignment of workspaces to specific Fabric capacities.
This is the most important configuration decision in our model because it determines whether workloads share the same compute risk domain.
Workspace assignment is the primary mechanism used to guarantee production isolation and operational independence.
The set of permissions allowing administrators to manage a capacity and move workspaces into or out of it.
Even with a good target architecture, weak governance can reintroduce risk if workspaces are moved without control.
A dedicated production capacity loses most of its value if workspace assignment is not tightly governed.
The sizing of Fabric capacity and the ability to adjust it as workload volume evolves.
Even a well-isolated architecture can fail operationally if the capacity is persistently undersized.
Data Platform Core capacity sizing must prioritize service continuity over cost minimization.
The monitoring of capacity usage, saturation patterns, top consumers, and operational degradation signals.
Capacity governance is only effective if usage and saturation can be observed and acted upon.
For each production capacity, define:
Capacity monitoring must be part of normal run operations, not only incident management.
The capacity-level disaster recovery posture associated with production data continuity.
The Data Platform Core workspace supports bronze and silver foundations, which makes it a core dependency for downstream exposure.
For Data Platform Core, disaster recovery should never be left undocumented.
Capacity-level settings related to Spark and Data Engineering workloads.
These settings are relevant if Spark-based processing is materially used in the platform.
This is a secondary topic unless Spark becomes a major production dependency.
Protect Data Platform Core by design.
Critical Core workloads must not depend on the same shared capacity behavior as variable Domain workloads.
Use isolation before optimization.
Do not try to solve structural contention only with reactive tuning.
Make monitoring part of standard operations.
Capacity review must be proactive and periodic.
Separate production from experimentation.
Development and testing workloads must not compete with critical production capacity.
The recommended target state for our platform is:
This is the most coherent model for a Fabric platform used primarily as a storage and exposure layer, where the Data Platform Core workspace must remain stable independently from Domain activity.