Microsoft Fabric Architecture: Components Explained, Layer by Layer
Microsoft Fabric architecture has three layers. At the bottom is OneLake, a single data lake per tenant that every engine reads and writes in Delta Parquet. In the middle is the SaaS platform: capacity (compute you pay for), workspaces (containers you organize by), Copilot, and Purview-backed governance. On top are the workloads: Data Factory, Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Databases, Fabric IQ, and Power BI. Below is each layer in turn, then the path a row of data takes from source system to report.
Product names, SKUs, and behavior were checked against Microsoft Learn in August 2026. Source links are at the end.
The architecture diagram, described in words
Microsoft's official diagram sits on the "What is Microsoft Fabric" page listed under Sources. It is a stack. Read it bottom to top.
- Storage layer: OneLake. One logical lake for the whole tenant, built on Azure Data Lake Storage Gen2. Tables are stored as Delta Parquet (or Iceberg). Shortcuts and mirroring bring outside data in without a copy.
- Platform layer (SaaS foundation). Three shared services that every workload inherits: - Capacity: the pool of compute, bought as an F SKU (F2 to F8192). Workspaces are assigned to a capacity, and every job in those workspaces draws from it. - Copilot: AI assistance inside each workload, bound by the same permissions as the user. - Governance: Microsoft Purview built in. Permissions, sensitivity labels, auditing, and the OneLake Catalog for discovery.
- Workload layer. Role-specific experiences that share the same storage and compute. Microsoft's current diagram groups them as Data Factory, Analytics (Data Engineering, Data Warehouse, Data Science), Databases, Real-Time Intelligence, Fabric IQ, and Power BI.
- Organizing structure that cuts across all layers. Tenant, then capacity, then workspace, then item. This hierarchy is how security, billing, and ownership are applied.
The design idea in one line: different engines (Spark, T-SQL, KQL, Analysis Services) pointed at one copy of data. Every other component exists to serve that.
Layer 1: OneLake, the storage foundation
- One per tenant, no provisioning. Every Fabric tenant gets exactly one OneLake. You cannot create a second one or delete it. There are no storage accounts, resource groups, or redundancy settings to manage.
- Open formats. Tables are Delta Parquet or Iceberg. Any tool that reads those formats can read your data, and Fabric's metadata virtualization lets Delta tables be read by Iceberg clients (Snowflake, for example) and vice versa.
- ADLS Gen2 API compatibility. Each workspace appears as a container and each item as a folder. Azure Databricks, Azure Storage Explorer, Synapse, and anything else that speaks the ADLS Gen2 API can connect.
- Shortcuts. A shortcut is a pointer to data somewhere else: another workspace, ADLS, Azure Blob, Amazon S3 and S3-compatible stores, Iceberg sources, Dataverse, or on-premises sources. The data stays where it is and appears as a local folder or table. This is the zero-copy pattern.
- Mirroring. Continuous near real-time replication of an operational database into OneLake as Delta Parquet. Supported sources include Azure SQL Database, Azure Cosmos DB, Azure Database for PostgreSQL, Azure Databricks (Unity Catalog), and Snowflake. You get an analytics-ready copy without writing ETL or hitting the production system with report queries.
- OneLake security. Access roles are defined once on the data (down to folder, table, row, or column) and enforced across every engine. If a user cannot see the Cost column in SQL, they cannot see it in a Spark notebook or a Power BI report either.
- Protection. Zone-redundant storage where the region supports it, locally redundant elsewhere, optional geo-replication to a paired region through capacity-level BCDR, and a seven-day soft delete.
The OneLake hierarchy
| Level | What it is | Who controls it |
|---|---|---|
| Tenant | The Microsoft Entra tenant. Root of OneLake. Tenant-level policies apply to everything underneath. | Fabric admin |
| Capacity | A pool of compute units, tied to one Azure region, billed separately. A tenant can have many. | Capacity admin |
| Workspace | A folder-like container assigned to one capacity. Holds items and carries its own roles (Admin, Member, Contributor, Viewer). | Workspace admin |
| Item | A lakehouse, warehouse, eventhouse, KQL database, notebook, pipeline, semantic model, report, and so on. | Item owner, plus OneLake security roles on the data |
Domains and sub-domains sit above workspaces as a logical grouping for federated ownership (Finance owns its workspaces, Sales owns theirs) while the catalog stays tenant-wide.
Layer 2: the platform services
Capacity
Compute in Fabric is bought, not configured. You choose an F SKU and every workload in the assigned workspaces draws from it. The SKU number is the number of capacity units (CUs). Capacity units measure compute power, so the table below compares compute, not licensing rights.
| SKU | Capacity units | Power BI SKU equivalent |
|---|---|---|
| F2 | 2 | (none) |
| F4 | 4 | (none) |
| F8 | 8 | EM/A1 |
| F16 | 16 | EM2/A2 |
| F32 | 32 | EM3/A3 |
| F64 | 64 | P1/A4 |
| Trial | 64 | (none) |
| F128 | 128 | P2/A5 |
| F256 | 256 | P3/A6 |
| F512 | 512 | P4/A7 |
| F1024 | 1024 | P5/A8 |
| F2048 | 2048 | (none) |
| F4096 | 4096 | (none) |
| F8192 | 8192 | (none) |
Architecture points that matter:
- F SKUs are bought through Azure and billed per second with a one-minute minimum, no commitment, with an optional yearly capacity reservation for a lower rate. You can pause a pay-as-you-go capacity.
- The Fabric trial runs for 60 days on a trial capacity worth 64 CUs, and for Power BI viewing it behaves like an F64.
- F64 is the licensing threshold for Power BI viewing. On F64 and above, a user with a free license and a viewer role can open reports. Below F64, every report viewer needs a Power BI Pro or Premium Per User license.
- Power BI Premium P SKUs are being retired in favor of F SKUs. PPU licenses do not provision a capacity and cannot run lakehouses, warehouses, or notebooks.
For the dollar figures behind each SKU, see the Microsoft Fabric pricing breakdown.
Governance (Purview and the OneLake Catalog)
Governance is not an add-on. Microsoft Purview is built into the platform layer, so sensitivity labels, access policies, and audit logs apply to every item the moment it is created. The OneLake Catalog is the front door: a tenant-wide view of every item, filterable by domain, workspace, item type, and endorsement, with lineage, owners, schema, and usage metrics attached. Data owners get a governance score and recommended fixes (missing labels, missing descriptions, untagged items). OneLake diagnostics can stream every data access event into a lakehouse so you can audit who touched what.
Copilot
Copilot appears inside the workloads (writing DAX, generating notebook code, building a pipeline, summarizing a report). It respects the user's existing permissions, so it cannot surface data the user could not already query. It runs on any paid capacity from F2 up, and every Copilot request burns capacity units from the capacity the workspace sits on, which is worth watching on a small SKU.
Layer 3: the workloads
Each workload is a set of item types plus an engine. The table shows what each one creates and which engine runs underneath.
| Workload | Main items | Engine | Typical owner |
|---|---|---|---|
| Data Factory | Pipelines, Dataflows Gen2, Copy job | Orchestration + Power Query (200+ connectors) | Data engineer, analyst |
| Data Engineering | Lakehouse, Notebook, Spark job definition, Environment | Apache Spark | Data engineer |
| Data Warehouse | Warehouse | T-SQL, the same SQL engine the lakehouse endpoint uses | SQL developer, BI developer |
| Real-Time Intelligence | Eventstream, Eventhouse, KQL database, Real-Time Dashboard, Activator | KQL (Kusto) | Streaming/IoT engineer |
| Data Science | ML model, Experiment, Notebook | Spark, with built-in experiment tracking and a model registry | Data scientist |
| Databases | SQL database in Fabric, Mirrored database | SQL Database engine, replication | App developer, DBA |
| Fabric IQ (preview) | Ontology, plan, Fabric Graph, data agent, operations agent, semantic model | Semantic and graph layer | Analytics architect |
| Power BI | Semantic model, Report, Dashboard, Paginated report | Analysis Services (Direct Lake, Import, DirectQuery) | Analyst, business user |
Microsoft also ships Industry Solutions, a set of prebuilt industry data models that sit on the same platform. Most mid-sized teams never touch them.
Notes on the ones that cause the most confusion:
- Lakehouse vs warehouse. Both store Delta tables in OneLake and both can be queried with T-SQL. The lakehouse is Spark-first and handles files and unstructured data; its SQL analytics endpoint is read-only and covers less of the T-SQL surface. The warehouse is T-SQL-first with full multi-table ACID transactions. You can, and often should, use both in one workspace. The full decision is in Lakehouse vs Warehouse in Microsoft Fabric.
- Eventhouse. The home for time-series and log data at high ingestion rates. KQL databases live inside it, and Activator triggers actions (email, Teams message, pipeline run) when a condition in the stream is met.
- SQL database in Fabric. A transactional Azure SQL-style database whose data is automatically replicated into OneLake, so an app's operational tables are queryable by Spark and Power BI without export.
- Fabric IQ. In preview as of August 2026. It adds an ontology (business definitions of entities like Customer or Order), a graph, and data agents so metrics mean the same thing across reports and AI tools. Preview means no production commitments, so keep it out of anything you have to support.
How data flows through the architecture
Here is the path a sales order takes from an ERP to a dashboard, naming the component at each step.
- Ingest. A Data Factory pipeline (or mirroring, if the source is a supported database) pulls the order into a lakehouse. The raw row lands in the lakehouse Files or Tables area in OneLake. Eventstream handles the same step for streaming sources such as IoT or clickstream.
- Transform. A Spark notebook cleans and conforms the data into Delta tables, usually in bronze, silver, and gold stages. The medallion architecture in Fabric post covers the layout.
- Model. Gold tables are either left in the lakehouse (queried through the SQL analytics endpoint) or loaded into a warehouse for dimensional modeling and multi-table transactions. Either way the tables are Delta files in OneLake.
- Serve. A Power BI semantic model points at those tables using Direct Lake mode, which reads the Parquet files directly instead of importing a copy or issuing live SQL queries. Reports and dashboards sit on top.
- Govern throughout. The OneLake Catalog registers every item, sensitivity labels inherit down the lineage, OneLake security roles filter rows and columns for each viewer, and capacity metrics show which step consumed which CUs.
- Act. Activator watches a KQL table or a Power BI measure and fires an alert or a Power Automate flow when a threshold is crossed.
The key architectural fact is that steps 1 through 4 never copy data out of OneLake. Spark writes a Delta table; T-SQL reads it; Analysis Services reads it. Same files.
Where the old Azure services went
If you are coming from Azure Synapse or a hand-built stack, the mapping is direct. Synapse Pipelines became Data Factory in Fabric. Synapse Spark pools became Data Engineering. Dedicated SQL pools became the Warehouse. Azure Data Explorer became Eventhouse and KQL databases. ADLS Gen2 accounts became OneLake. The Synapse vs Fabric migration guide goes through what changes in practice.
What did not move into Fabric: Azure Databricks, Azure SQL Database, and Cosmos DB remain separate services, but all three can be mirrored or shortcut into OneLake.
Architecture decisions you have to make on day one
Fabric removes infrastructure decisions but leaves five that shape everything later.
- How many capacities, and in which regions. One capacity per region you need data residency in, plus a separate capacity for development if you want to keep test workloads from slowing production reports. Each workspace belongs to one capacity.
- Workspace layout. Common patterns are one workspace per environment per domain (Finance-Dev, Finance-Prod) or one per medallion layer. Workspaces are the unit of deployment pipelines, Git integration, and access control, so the layout sets your CI/CD model.
- Lakehouse, warehouse, or both. Spark-heavy teams and mixed data go lakehouse. SQL-only teams doing star schemas go warehouse. Most mid-sized setups land data in a lakehouse and serve from either.
- Copy or point. For each external source decide between a shortcut (live, zero copy, read-only), mirroring (near real-time replicated copy, supported databases only), or a pipeline (scheduled copy, any of the 200+ connectors, full transformation control).
- F SKU size. Start small (F2 to F16 is typical for a pilot), watch the Capacity Metrics app, and scale. The F64 threshold only matters once you have many report viewers without Pro licenses.
Frequently asked questions
Is Microsoft Fabric PaaS or SaaS? SaaS. You do not create storage accounts, clusters, or resource groups. You buy a capacity, create workspaces, and every engine is already wired to OneLake. You do not even need an Azure account to use Fabric, though F capacities are purchased and billed through Azure.
What is the difference between OneLake and Azure Data Lake Storage? OneLake is built on ADLS Gen2 but is managed by Fabric. There is exactly one OneLake per tenant, you cannot create more or delete it, and it speaks the ADLS Gen2 API so existing tools can connect to it. Think of ADLS as the disk and OneLake as the single organization-wide file system on top of it.
Does every Fabric workload store data in its own format? No. The warehouse, lakehouse, eventhouse, mirrored databases, and SQL database in Fabric all land tables in OneLake as Delta Parquet (Iceberg is also supported through metadata virtualization). That shared format is what lets Spark, T-SQL, KQL, and Power BI read the same copy.
Do I need F64 to use Fabric? No. Any F SKU from F2 upwards runs every workload. F64 matters only for Power BI viewing: on F64 and above, users with a free license and a viewer role can open reports; below F64 each viewer needs a Power BI Pro or PPU license.
Where does Power BI sit in the Fabric architecture? Power BI is one of the workloads on top of the platform layer, not a separate product bolted on. Semantic models read OneLake directly through Direct Lake mode, so a report can query lakehouse or warehouse tables without importing a copy.
Sources
- What is Microsoft Fabric, Microsoft Learn, checked August 2026
- OneLake, the unified data lake, Microsoft Learn, checked August 2026
- Microsoft Fabric licenses and capacity, Microsoft Learn, checked August 2026
Where Maxwize fits
Maxwize designs and builds Fabric environments for small and mid-sized companies: capacity sizing, workspace and domain layout, lakehouse or warehouse design, and Power BI on top. Data analytics projects run from $1,000 to $20,000 depending on sources and scope. If you want a second opinion on an architecture before you commit to a capacity, see our Microsoft Fabric service page or get in touch.