Microsoft Fabric Architecture Explained: OneLake, Workspaces, and Capacity
Last Updated on September 25, 2026 by Editorial Team
Author(s): Hexaview Technologies
Originally published on Towards AI.
Microsoft Fabric Architecture Explained: OneLake, Workspaces, and Capacity

Microsoft Fabric architecture brings data engineering, data integration, data warehousing, real-time analytics, data science, databases, and Power BI into a unified SaaS platform. At the center is OneLake, Fabric’s organization-wide logical data lake. Capacities provide the compute resources that run Fabric workloads, while workspaces organize teams, permissions, and projects. Within those workspaces, Fabric items such as lakehouses, warehouses, pipelines, notebooks, semantic models, and reports perform specific tasks. Together, these layers create a connected architecture for ingesting, processing, governing, analyzing, and visualizing enterprise data.
What Is Microsoft Fabric Architecture?
Microsoft Fabric architecture is the structural framework that connects data storage, compute, analytics workloads, and governance within one SaaS platform. Instead of requiring separate services for data integration, engineering, warehousing, real-time analytics, data science, and business intelligence, Fabric brings these experiences together under a shared architecture.
A simplified view looks like this:
Microsoft 365 Tenant → Fabric Capacity → Workspaces → Fabric Items → OneLake
This flow is a simplified representation rather than a strict execution sequence. Fabric workloads use the shared platform to perform specialized processing and analytics tasks.
At the foundation, OneLake provides a unified logical data lake for an organization. It helps reduce duplicated data stores and enables different Fabric workloads to work with shared data. Fabric capacity provides the compute resources used to run workloads. Workspaces organize projects, users, permissions, and content. Fabric items include lakehouses, warehouses, pipelines, notebooks, semantic models, reports, and other resources used to work with data.
The key difference from a collection of disconnected analytics services is this shared foundation. Teams can use different workload experiences while operating within the same platform and data environment.
Fabric follows a Software as a Service (SaaS) approach. Microsoft manages much of the underlying infrastructure, allowing organizations to focus on data and analytics rather than managing individual platform components.
Governance also spans the architecture. Security, identity, permissions, data management, and compliance capabilities can operate across workloads. This creates a more connected environment for ingestion, transformation, real-time processing, analytics, and reporting.
Microsoft Fabric Architecture at a Glance
The following simplified diagram shows how the major layers of Microsoft Fabric architecture relate to each other:

Each layer has a distinct architectural purpose. The tenant provides the organizational boundary. Fabric capacities provide the compute resources used by workloads. Workspaces organize users, projects, permissions, and content. Fabric items are the individual resources teams create and use.
OneLake provides the shared logical storage foundation across Fabric. Workloads such as Data Factory, Data Engineering, Data Science, Data Warehouse, Real-Time Intelligence, Databases, and Power BI use these platform layers for specialized tasks.
Governance and security span the architecture, with identity, access controls, permissions, and data governance applying across relevant resources and workloads.
OneLake: The Foundation of Microsoft Fabric Architecture
What Is OneLake?
OneLake is the unified data lake built into Microsoft Fabric architecture. Every Fabric tenant includes OneLake, giving organizations a shared logical data foundation for their analytics workloads. It is built on Azure Data Lake Storage Gen2 (ADLS Gen2) capabilities while providing a managed experience within Fabric.
Organizations do not need to create separate data lakes for every Fabric workload. Instead, different teams and workloads can work with data through the same OneLake environment.
OneLake Data Hierarchy
A simple way to understand OneLake is:
Tenant → Workspaces → Items → Data
Think of this structure like an organization:
- Tenant: The organization
- Workspace: A department or project area
- Item: A specific data or analytics resource
- OneLake: The shared data foundation
This structure helps teams organize data while maintaining a common storage layer.
One Copy of Data
OneLake can help reduce unnecessary data duplication and movement. Its shortcuts allow users to reference data stored elsewhere without physically copying it into another location.
Shortcuts can support access across workspaces and data sources. This allows different Fabric workloads to reuse data instead of creating multiple copies for each analytical requirement.
As a result, organizations can simplify data access while reducing repetitive storage and movement.
OneLake and Open Data Formats
OneLake supports open data approaches, including Delta and Parquet formats. It also works with ADLS Gen2 storage capabilities. This helps organizations work with widely used data formats while using Fabric’s integrated analytics experiences.
Fabric Workspaces: The Organizational Layer
What Is a Fabric Workspace?
A Fabric workspace is a container for organizing Fabric items, users, permissions, and collaborative work. It provides an important boundary for collaboration, access control, ownership, development, deployment, and governance.
Workspaces help enterprises separate projects and teams while managing access to the resources they create.
What Can a Workspace Contain?

Workspace Roles
Fabric provides workspace roles with different permission levels:
- Administrator: Manages workspace settings, access, and content.
- Member: Collaborates on workspace content and manages relevant resources.
- Contributor: Creates and modifies workspace content.
- Viewer: Views content without making changes.
Workspace permissions should not be confused with granular data-level security. For example, controlling access to a workspace does not automatically determine which rows a user can see within a semantic model.
How Should Enterprises Structure Workspaces?
Enterprises can organize workspaces by business unit, project, data domain, environment, development lifecycle, or workload. Each approach has trade-offs. Business-unit structures can simplify ownership but create duplication. Project-based structures improve isolation but may increase administration. Environment-based structures support development and deployment, while domain-based structures can align better with data ownership.
Fabric Capacity: The Compute and Resource Layer
One of the most important concepts in Microsoft Fabric architecture is capacity. It determines how Fabric workloads receive shared compute resources.
What Is Fabric Capacity?
Fabric capacity is a compute and billing resource that provides processing resources for Fabric workloads. A capacity is associated with a specific Azure region, while workspaces can be assigned to that capacity. Multiple workspaces can operate on the same capacity, allowing organizations to share available compute resources across teams and workloads.
This creates an important separation in Fabric architecture. Workspaces organize content and collaboration, while capacity provides the resources required to process that content.
Capacity Units
Fabric uses Capacity Units (CUs) as a conceptual measure of compute consumption. Different operations consume different amounts of available capacity depending on their processing requirements.
CUs help organizations understand how workloads use shared compute resources. They are therefore important for capacity planning, monitoring, and performance management rather than simply representing a fixed amount of processing power.
Why Does Capacity Matter?
Capacity directly affects performance, concurrency, scaling, workload isolation, governance, and cost management. Organizations must consider how many workloads run simultaneously and how demanding those workloads are.
Capacity monitoring can also help identify inefficient or resource-intensive operations before they affect other workloads.
What Happens When Capacity Is Overloaded?
When multiple workloads compete for limited capacity, CU consumption can increase significantly. Sustained excessive consumption can cause throttling, which may temporarily delay or reject transactions.
Fabric capacity monitoring helps administrators identify these conditions and understand which workloads are consuming resources. This supports better workload management, capacity planning, and performance optimization.
How OneLake, Workspaces, and Capacity Work Together?

The relationship between OneLake, workspaces, and capacity becomes clearer when viewed through a practical data workflow. Consider a company that receives millions of customer transactions each day and wants to turn that data into business insights.
Step 1: Data Enters Fabric
The company uses Data Factory to connect to transaction systems and ingest customer data. Pipelines can schedule and orchestrate the movement of data into Fabric.
Step 2: Data Is Stored in a Lakehouse
The incoming data is loaded into a Lakehouse within an appropriate Fabric workspace. The Lakehouse provides a data engineering environment for storing and working with the information.
Step 3: Data Resides in OneLake
The Lakehouse’s data is stored within OneLake, Fabric’s shared data foundation. This allows other Fabric experiences to work with the same underlying data without requiring unnecessary copies.
Step 4: Data Engineering Transforms the Data
Data engineers use Data Engineering tools and notebooks to clean, transform, and prepare transaction records. For example, they might remove duplicate records or standardize customer and transaction fields.
Step 5: Data Is Prepared for Analytics
The processed data can then support a Data Warehouse or semantic model. These layers organize business-ready information for analytical queries and reporting.
Step 6: Power BI Uses the Data
Power BI can consume the prepared data through semantic models and create dashboards and reports for business users.
Step 7: Capacity Provides Compute
Throughout these operations, Fabric capacity provides the compute resources required by the workloads. Multiple workloads can consume resources from the assigned capacity.
Step 8: Workspaces Control Access
Finally, workspace permissions determine who can view, create, modify, or manage the resources. This separates organizational access from the underlying data storage and compute layers.
Together, these layers create a connected architecture: workspaces organize resources, OneLake provides shared storage, and capacity supplies compute.
Core Workloads Within Microsoft Fabric Architecture

Microsoft Fabric brings multiple specialized workloads together on a shared platform. Each experience addresses a different stage of the data lifecycle while using common architectural foundations such as OneLake, workspaces, and capacity.
Data Factory
Data Factory handles data ingestion, movement, and orchestration. Teams can create pipelines that connect source systems with Fabric destinations and coordinate multi-step data workflows.
Data Engineering
Data Engineering provides tools for working with large-scale data using Spark, notebooks, and Lakehouses. Engineers can transform, clean, and prepare data for downstream analytical workloads.
Data Warehouse
Data Warehouse supports SQL-based analytics and structured workloads. It can organize prepared data for enterprise reporting, analytical queries, and business applications.
Data Science
Data Science supports machine learning, model development, experimentation, and analytical exploration. Data scientists can work with data available through Fabric while developing and evaluating models.
Real-Time Intelligence
Real-Time Intelligence addresses workloads involving streaming data, event processing, and real-time analytics. It helps organizations analyze information as events occur rather than relying only on batch processing.
Databases
Fabric Databases support transactional and operational data scenarios while connecting those workloads with the broader Fabric analytics environment. This helps reduce separation between operational data and analytical workflows.
Power BI
Power BI provides the business intelligence layer through semantic models, reports, and dashboards. It converts prepared data into interactive insights for business users.
Copilot and AI
Copilot adds AI-assisted capabilities across relevant Fabric experiences. It can help users explore data, develop content, and accelerate certain analytical tasks. However, Copilot does not replace the underlying architecture. It operates on top of Fabric’s data, security, compute, and governance foundations.
How Data Flows Through Microsoft Fabric Architecture?

A typical Microsoft Fabric architecture connects data sources, ingestion, storage, processing, modeling, analytics, and governance. The exact flow can vary by workload, but the following sequence provides a practical enterprise view.
Stage 1: Data Sources
Data can originate from many systems, including:
- ERP platforms
- CRM systems
- SaaS applications
- Databases
- APIs
- Files
- Streaming sources
These systems generate operational, transactional, customer, and event data.
↓
Stage 2: Data Ingestion
Data Factory and other Fabric ingestion capabilities connect to these sources. Pipelines can orchestrate data movement and schedule recurring ingestion processes.
↓
Stage 3: OneLake Storage
Ingested data can be stored within OneLake, Fabric’s unified data foundation. Depending on the workload, data can be organized through Fabric items such as Lakehouses and Warehouses.
↓
Stage 4: Data Processing
Fabric workloads process and refine the data. Data Engineering, notebooks, Spark, SQL, and other capabilities can support cleaning, transformation, enrichment, and preparation.
↓
Stage 5: Data Modeling
Processed data is organized into analytical structures. Teams can create tables, semantic models, business logic, relationships, and other analytical structures that make data easier to interpret.
↓
Stage 6: Analytics
Power BI and other Fabric analytical experiences consume prepared data. Users can explore information through semantic models, reports, dashboards, and analytical applications.
↓
Stage 7: Governance and Monitoring
Governance operates across the environment. Organizations can manage security, permissions, lineage, monitoring, and data governance while tracking how data moves through different workloads.
This creates a connected flow from source systems to actionable business insights, while shared Fabric services provide the underlying architectural foundation.
Microsoft Fabric Architecture and Medallion Architecture
Medallion architecture is a common data design pattern that organizes data into progressive layers: Bronze, Silver, and Gold. Microsoft Fabric can support this approach using Lakehouses, Warehouses, pipelines, notebooks, and other Fabric items.
Bronze: Raw Data
The Bronze layer contains raw or minimally processed data. It can preserve information as it arrives from source systems, providing a reliable starting point for downstream processing.
Silver: Cleaned Data
The Silver layer contains cleaned, validated, and transformed data. Data engineers can standardize fields, remove duplicates, apply quality rules, and prepare datasets for analytical use.
Gold: Business-Ready Data
The Gold layer contains curated, business-ready data. It can include aggregated datasets, analytical tables, and structures designed for reporting, dashboards, and business intelligence.
A Fabric implementation might organize these layers across separate workspaces:
Bronze Workspace → Silver Workspace → Gold Workspace
Alternatively, organizations may use separate items within fewer workspaces. The choice depends on security requirements, team ownership, deployment processes, and operational complexity.
Separating layers can provide clearer ownership and access boundaries. However, it can also introduce additional administration and deployment considerations.
Importantly, medallion architecture is a design pattern, not a mandatory Microsoft Fabric architecture. Organizations can adopt it where the layered approach fits their data requirements. Fabric’s architecture does not require every implementation to use Bronze, Silver, and Gold layers.
Microsoft Fabric Architecture for Enterprise Environments
The right Microsoft Fabric architecture can change significantly as an organization grows. A small team may need only a few workspaces and limited governance, while a global enterprise may require multiple capacities, domains, environments, and stronger operational controls.
Small Environment
Smaller organizations can often start with a relatively simple architecture:
- Fewer workspaces
- A centralized capacity
- Shared development resources
- Simpler governance and access controls
This approach reduces administrative overhead and can make it easier for a small team to manage its Fabric environment.
Mid-Sized Environment
As teams and workloads increase, organizations may introduce greater separation:
- Multiple business or project workspaces
- Shared capacity across teams
- Separate development and production environments
- Formal governance policies
- More structured access management
At this stage, workspace organization becomes increasingly important because multiple teams may share the same Fabric resources.
Large Enterprise
Large organizations often require a more distributed architecture. Common considerations include:
- Multiple capacities for scale and workload isolation
- Domain-based organization aligned with business or data ownership
- Dedicated resources for demanding workloads
- Regional considerations for data residency, performance, and operational requirements
- Strong identity, security, and access controls
- CI/CD and structured deployment processes
- Centralized governance with delegated ownership
A large enterprise may therefore combine centralized standards with decentralized execution. A central data or platform team can establish security, governance, and architecture standards, while individual domains manage their own workspaces and data products.
The goal is not to make the architecture as complex as possible. It is to introduce structure where organizational scale, workload requirements, security, and operational needs justify it.
How Microsoft Fabric Capacity Affects Performance and Cost?
Capacity planning is an important part of Microsoft Fabric architecture because compute availability affects workload performance, concurrency, and resource consumption. However, capacity should not be confused with storage.
Capacity Sizing
Organizations need to consider workload volume, processing requirements, user activity, and concurrency when determining appropriate capacity. A capacity that works for a small team may not provide sufficient resources as workloads grow.
Workload Concurrency and CU Consumption
Multiple workloads can use the same capacity simultaneously. Data pipelines, notebooks, SQL queries, semantic models, and reports may therefore compete for available compute resources. Capacity Units (CUs) provide a way to understand this compute consumption.
Storage Versus Compute
A key architectural distinction is that OneLake storage and Fabric compute are separate concepts. OneLake provides the shared storage foundation, while Fabric capacity provides compute resources for workloads.
However, operations performed against OneLake can consume Fabric capacity resources. Therefore, storage volume and compute consumption should be considered separately when planning an environment.
Monitoring and Workload Isolation
Capacity monitoring helps administrators identify resource-intensive workloads, concurrency patterns, and potential bottlenecks. Organizations may also use separate capacities to isolate demanding workloads from other teams or business-critical processes.
Scaling and Pausing
Organizations can adjust capacity based on workload requirements. Depending on the capacity type and configuration, scaling can provide additional compute resources, while pausing can stop compute usage when a capacity is not required.
Throttling
When workloads consume capacity beyond available resources, Fabric can apply throttling. This can delay or temporarily reject operations. Monitoring CU consumption helps administrators identify these conditions and make informed decisions about workload optimization or capacity changes.
Overall, effective capacity planning requires balancing performance, concurrency, workload requirements, and cost rather than treating storage and compute as the same resource.
How a Microsoft Fabric Consulting or Implementation Agency Can Help?
A Microsoft Fabric consulting or implementation agency can support organizations across architecture, migration, governance, implementation, and optimization. The exact scope depends on the organization’s existing data environment, workloads, and operating model.
Architecture Assessment
The engagement may begin with an assessment of existing data platforms and workflows. Consultants can review SQL environments, data lakes, BI platforms, and integration tools to identify data silos, duplicated processes, workload dependencies, and architectural constraints. They can then document the current-state architecture.
Target Architecture Design
The next stage can define the target Fabric architecture. This may include designing the OneLake structure, workspace strategy, capacity requirements, security boundaries, and Fabric workload placement. The objective is to create an architecture that aligns with technical and organizational requirements.
Migration Planning
For organizations moving from existing SQL platforms or data lakes, implementation teams can assess migration dependencies and determine which datasets and workloads should move first. A phased migration plan can reduce operational disruption and establish clear milestones.
Security and Governance
Architecture teams can design workspace permissions, data access policies, governance structures, and security controls. They may also integrate Fabric with existing enterprise governance and security tools.
Capacity Planning
Consultants can estimate workload requirements, analyze CU consumption, identify performance bottlenecks, and develop capacity scaling strategies.
Implementation
Implementation work can include configuring workspaces, building pipelines, creating Lakehouses and Warehouses, developing notebooks, configuring semantic models, and establishing deployment processes.
Testing and Optimization
Teams may perform performance testing, capacity monitoring, query optimization, pipeline optimization, and cost analysis before and after production deployment.
Ongoing Architecture Management
After implementation, organizations may continue reviewing architecture changes, capacity usage, new workloads, governance requirements, migration progress, and performance patterns.
This makes an implementation partner’s role broader than simply deploying Fabric. It can involve architecture, implementation, migration, governance, performance optimization, and ongoing platform management.
Microsoft Fabric Architecture vs Traditional Data Architecture
The architectural difference between Microsoft Fabric and a traditional data environment is primarily about how services are organized and connected. Traditional architectures often combine independently provisioned platforms, while Fabric brings multiple data and analytics experiences into a shared SaaS environment.

In a traditional environment, a data lake, ETL platform, engineering environment, warehouse, and BI tool may be purchased and operated separately. Each component can have its own configuration, security model, monitoring approach, and infrastructure requirements.
Fabric instead provides these capabilities through a common platform. OneLake provides the shared data foundation, while Fabric workloads provide specialized experiences for ingestion, engineering, warehousing, analytics, and visualization. Shared capacity provides compute resources across supported workloads.
This does not mean every traditional component becomes unnecessary. Organizations may continue using external databases, cloud services, specialized analytics platforms, governance products, or other technologies when business or technical requirements call for them.
Therefore, the architectural distinction is less about replacing every existing technology and more about consolidating connected data and analytics capabilities around a shared platform.
Final Takeaway
A successful Microsoft Fabric architecture connects several layers into one coordinated environment. OneLake provides the shared data foundation. Workspaces organize data, workloads, collaboration, and permissions. Capacity provides the compute resources that run Fabric workloads. Fabric experiences then support specialized needs across engineering, integration, warehousing, real-time analytics, data science, databases, and BI.
Effective implementation requires more than enabling Fabric. Organizations need to design the right data organization, workspace structure, capacity model, security framework, governance model, and deployment lifecycle. Architecture teams or implementation agencies can support these decisions through assessment, migration planning, implementation, governance, testing, and optimization.
Frequently Asked Questions
What is Microsoft Fabric architecture?
Microsoft Fabric architecture is the framework that connects storage, compute, workspaces, data workloads, analytics, and governance within Fabric. It uses shared platform components such as OneLake, capacities, and workspaces to support end-to-end data workflows.
What is OneLake in Microsoft Fabric?
OneLake is Fabric’s unified logical data lake. It provides a shared data foundation for Fabric workloads and helps reduce unnecessary data duplication across analytical processes.
What is the difference between OneLake and a workspace?
OneLake provides the shared data storage foundation, while a workspace provides an organizational and collaboration boundary for Fabric items, users, permissions, and projects.
What is a Microsoft Fabric workspace?
A Fabric workspace is a container for Fabric items such as Lakehouses, Warehouses, pipelines, notebooks, semantic models, reports, and other resources. It also provides a boundary for collaboration and access management.
What is Fabric capacity?
Fabric capacity provides the compute resources used by Fabric workloads. It is also a billing resource associated with an Azure region and can support multiple workspaces.
How do workspaces and capacities work together?
A workspace can be assigned to a Fabric capacity. The items and workloads operating within that workspace can then consume compute resources from the assigned capacity.
Does every Fabric tenant have OneLake?
Yes. Microsoft describes OneLake as the unified data lake for a Fabric tenant. It is automatically available as part of the Fabric environment.
Can multiple workspaces share one Fabric capacity?
Yes. Multiple workspaces can be assigned to and operate on the same capacity. This allows organizations to share available compute resources across teams and workloads.
When should an organization use multiple Fabric capacities?
Multiple capacities may be appropriate when organizations need workload isolation, different performance requirements, regional considerations, or greater control over resource consumption. The decision depends on workload patterns, governance requirements, and operational needs.
How does Microsoft Fabric support data governance?
Fabric supports governance through capabilities for identity, permissions, access control, lineage, monitoring, and data management. Organizations can combine Fabric governance features with broader enterprise security and governance practices.
What role does Power BI play in Fabric architecture?
Power BI provides the business intelligence and visualization layer. Semantic models, reports, and dashboards allow users to consume prepared data and turn it into interactive business insights.
Can a Microsoft Fabric consulting agency help design the architecture?
Yes. A consulting or implementation agency can assist with architecture assessment, target architecture design, migration planning, security, governance, capacity planning, implementation, testing, and optimization.
What should organizations consider before implementing Microsoft Fabric?
Organizations should assess their existing data architecture, workloads, data volumes, security requirements, governance model, workspace strategy, capacity requirements, migration dependencies, and operating model. They should also determine which existing platforms should integrate with Fabric and which workloads are suitable for migration.
Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.
Published via Towards AI
Towards AI Academy
We Build Enterprise-Grade AI. We'll Teach You to Master It Too.
15 engineers. 100,000+ students. Towards AI Academy teaches what actually survives production.
Start free — no commitment:
→ 6-Day Agentic AI Engineering Email Guide — one practical lesson per day
→ Agents Architecture Cheatsheet — 3 years of architecture decisions in 6 pages
Our courses:
→ AI Engineering Certification — 90+ lessons from project selection to deployed product. The most comprehensive practical LLM course out there.
→ Agent Engineering Course — Hands on with production agent architectures, memory, routing, and eval frameworks — built from real enterprise engagements.
→ AI for Work — Understand, evaluate, and apply AI for complex work tasks.
Note: Article content contains the views of the contributing authors and not Towards AI.