Microsoft Fabric explained

Microsoft Fabric is Microsoft's unified analytics platform: data integration, engineering, warehousing, data science, real-time analytics, and Power BI, all sold as one product on one capacity, storing data in one lake. If you're a Microsoft 365 administrator, you've probably met it as a line on the Power BI renewal quote and a wave of new icons in the Power BI portal — and the easy conclusion is that Fabric is Power BI Premium with a new badge.

That conclusion is wrong in a way that matters. Power BI is one workload of seven-plus inside Fabric, and the rest of the platform is Microsoft's answer to an entire category — the Snowflake/Databricks-shaped modern data stack — packaged so it shows up inside a Microsoft 365 tenant. Since Power BI capacity is Fabric capacity now, the wider platform is part of your estate whether you asked for it or not. Here's the actual shape of it.

OneLake: the idea that holds Fabric together

Everything in Fabric sits on OneLake — a single, logical data lake provisioned automatically for the whole tenant. The marketing line is "OneDrive for data," and for once the analogy earns its keep: one lake per organisation, organised by workspace, with no storage accounts to create, secure, or name.

Three properties make OneLake more than storage:

• One copy of the data, open formats. Fabric workloads store tabular data as Delta Parquet — an open format, not a proprietary database file. The warehouse, the Spark notebooks, the SQL endpoints, and Power BI all read the same files. The traditional analytics pipeline — copy from the lake into the warehouse, copy from the warehouse into the BI model — collapses into different engines over one copy.
• Shortcuts. A shortcut mounts external storage — Azure Data Lake Storage, Amazon S3, Google Cloud Storage, Dataverse — into OneLake without moving or duplicating the data. This is also how Dynamics 365 data reaches Fabric ("link to Fabric" from Power Platform), which the sister guide on Fabric and Dynamics 365 covers in depth.
• Direct Lake for Power BI. Semantic models can read Delta tables straight from OneLake, giving import-mode speed without import-mode copies and refresh schedules. That's the headline architectural win for BI teams, detailed in Power BI, Fabric, and semantic models.

If you remember one thing about Fabric, make it OneLake. The workloads are engines; the lake is the platform.

The workloads

Fabric presents itself as a set of workloads ("experiences") over OneLake:

• Power BI — the reporting and semantic-model layer you already know, unchanged in its fundamentals.
• Data Factory — pipelines and Dataflows Gen2 for data integration; the Fabric-native evolution of Azure Data Factory and the Power Query dataflows lineage (Power BI dataflows covers the ancestry).
• Data Engineering — Spark notebooks and lakehouses (Delta tables plus files in a workspace) for transformation at scale.
• Data Science — ML model training and experimentation, MLflow-flavoured, on the same Spark pools.
• Data Warehouse — a T-SQL warehouse over OneLake, for teams that think in SQL and want warehouse semantics without managing one.
• Real-Time Intelligence — ingestion and querying of streaming and event data using KQL (the Kusto engine behind Azure Data Explorer and Defender's advanced hunting), plus Activator for event-driven alerts and actions — "when this metric crosses that line, trigger the flow."
• Databases — operational SQL databases inside Fabric, the newest addition, aimed at transactional workloads whose data should land in the lake by default.

Plus Copilot in Fabric and AI functions threaded through the workloads — natural-language notebook and DAX assistance, and data agents that answer questions over governed data. Treat the AI layer as an accelerant for practitioners, not a reason to buy the platform.

The honest read: Power BI, Data Factory, Data Engineering, and Warehouse are the workloads most organisations touch in year one. Real-Time Intelligence and Data Science are excellent but specialised. Databases is young — watch it, don't bet the estate on it yet.

Licensing: F-SKUs, and the end of the P-SKU

Fabric is sold as capacity — a pool of compute (measured in Capacity Units) shared by everything you run — via Azure as F-SKUs: F2, F4, F8, F16, F32, F64, F128, and on up, each doubling capacity and price. Alongside capacity, per-user licences still exist: Free, Pro, and Premium Per User, with the trade-offs covered in Pro vs PPU vs Fabric capacity.

The rules that decide what you actually pay:

• Authors need Pro (or PPU) regardless of capacity. Capacity never replaces authoring licences.
• F64 is the magic line. At F64 and above, report viewers don't need Pro — free-licence users can consume Power BI content, the old Premium P1 value proposition. Below F64, everyone touching Power BI content needs Pro, and the small capacity is buying Fabric workloads plus performance, not viewer licensing.
• F-SKUs are Azure resources: pay-as-you-go by the hour with pause/resume, or reserved pricing for roughly a 40% discount. Small F-SKUs make real experimentation cheap — an F2 costs a few hundred dollars a month, and a paused capacity costs nothing but storage.
• The P-SKUs are gone. The old Power BI Premium P1/P2 SKUs have been retired from sale, and renewals have been steered onto F-SKUs (F64 standing in for P1, F128 for P2). If your organisation still budgets in "Premium P1" terms, the renewal conversation has already changed underneath you.

One operational note: capacity is shared and finite. Fabric smooths and throttles usage, and a runaway Spark job and the CFO's dashboards can be tenants of the same F-SKU. Someone needs to own capacity monitoring — that's a new admin duty that didn't exist when "Premium" meant only Power BI.

Where Azure Synapse fits

Fabric is the successor to Azure Synapse Analytics. The Synapse workload names inside Fabric weren't subtle, and Microsoft's investment and roadmap now run through Fabric: new capability lands there, and official migration guidance exists for moving Synapse dedicated SQL pools, Spark workloads, and pipelines to their Fabric equivalents. Existing Synapse deployments keep working as Azure services, but nobody should start on Synapse in 2026, and teams running it should have a Fabric evaluation on the roadmap rather than assume the platform will develop further.

The same logic applies more broadly: Fabric is where Microsoft consolidated a decade of overlapping data products. That consolidation is the pitch — one bill, one security and governance model (with Purview integration), one copy of the data — and also the risk, because you're adopting a platform, not a tool. Governance questions (who can create workspaces, where capacity budget lives, how OneLake data gets classified) deserve answers before enthusiastic teams sprawl across a shared capacity.

The bottom line

Fabric is not Power BI Premium rebranded; it's Microsoft's whole data platform with Power BI as its most familiar face. If your organisation's needs end at dashboards, you can keep treating it that way — buy the capacity Power BI needs and ignore the rest. But if there's a data warehouse, an ETL estate, or a streaming use case anywhere in the building, Fabric turns them from separate Azure projects into workloads on capacity you already own. That's worth understanding on purpose rather than discovering by invoice.