What Is Microsoft Fabric? A Plain-English Explainer (and What It Costs)

The Scenario: A BI Team Drowning in Its Own Stack

Imagine a BI team supporting a group of product managers:

• Data lands in Azure Data Lake Storage via scheduled Azure Data Factory pipelines.
• A separate Azure Synapse SQL pool holds curated tables.
• Data scientists pull copies into Databricks.
• Power BI uses import models fed from Synapse.
• Every environment has its own permissions, cost center, and logging.

Pain points:

• Too many moving parts – every change to upstream data hits 3–4 services.
• Cost is opaque – no one can easily see which workloads are burning money.
• Governance is fragmented – security and lineage differ per service.

The team hears that Fabric could simplify this, but wants to know concretely:

1. What exactly is Fabric (and what is it not)?
2. How does it change their daily work (especially the lake and warehouse pieces)?
3. What does it cost compared to their current mix of services?

We’ll keep coming back to this team as we unpack Fabric.

What Microsoft Fabric Actually Is

Microsoft Fabric is a unified analytics SaaS platform that bundles multiple workloads into one product, all running on a shared capacity and a shared OneLake data foundation.

Key points that matter in practice:

• Fabric is SaaS: you don’t deploy or patch clusters; you buy capacity and use workspaces.
• Fabric is capacity-based: most production use runs on F SKUs (Fabric capacity), not per-user Pro-only.
• Fabric is workload-unified: Data Engineering, Data Factory, Data Science, Data Warehouse, Real-Time Analytics, Power BI, and Data Activator all live in the same tenant and workspaces.
• Fabric is OneLake-first: the default storage for Fabric items is OneLake, with shortcuts to external data.

For our BI team, this means:

• Instead of Azure Data Factory + Synapse + Power BI, they get Fabric Pipelines, Lakehouses, Warehouses, and Power BI in one workspace.
• Capacity and governance become tenant-level concerns, not per-service.

Fabric is not:

• A drop-in replacement for every existing Azure data service.
• A way to keep your current set of P SKUs and just “turn on Fabric” without thinking about capacity.

Core Building Blocks: OneLake, Workspaces, and Capacities

OneLake: The Storage Foundation

OneLake is the logical data lake behind Fabric. Technically, it’s built on Azure Data Lake Storage Gen2, but Fabric abstracts that away.

Important behaviours:

• Data in Lakehouses and Warehouses is stored in OneLake.
• Lakehouses use Delta Lake format (Parquet + transaction log) for tables.
• You can create shortcuts to external data (e.g. ADLS Gen2, Amazon S3), so Fabric can query that data without copying it.
• Power BI Direct Lake models can read Lakehouse tables directly from OneLake without importing into VertiPaq.

For the BI team:

• Their curated tables can live in a Lakehouse or Warehouse backed by OneLake.
• The same data can feed Power BI (Direct Lake or import) and SQL-style queries without separate ETL copies.

Workspaces: The Logical Boundary

Fabric uses workspaces (similar to Power BI workspaces) as the main boundary for:

• Items (Lakehouses, Warehouses, Pipelines, Notebooks, Reports, etc.).
• Security (workspace roles, item-level permissions).
• Capacity assignment (each workspace is either on a Fabric capacity or not).

For the BI team:

• They can have one workspace per product area, containing pipelines, Lakehouses, semantic models, and reports for that domain.

Capacities: How Fabric Runs (and Bills)

Fabric workloads run on capacities:

• F SKUs (Fabric capacities) are the main production option.
• Power BI P SKUs can also run Fabric workloads in some configurations, but F SKUs are the default going forward.
• Capacity defines available compute; items in workspaces assigned to that capacity consume it.

Key behaviours:

• If a workspace is not on a capacity, you’re limited to what can run on shared infrastructure (e.g. Pro-level Power BI features, some trial workloads).
• If a workspace is on a capacity, Fabric workloads (e.g. Lakehouse queries, pipelines) consume that capacity’s resources.

This is where cost really starts to matter, which we’ll come back to.

Workloads in Fabric: What You Actually Use

Here’s how the main workloads map to things you already know.

Data Engineering: Lakehouses and Notebooks

Data Engineering in Fabric gives you:

• Lakehouse: Delta Lake–backed tables and files in OneLake, optimized for analytics.
• Notebooks: Spark-based notebooks for data prep, engineering, and data science.

For the BI team:

• Their curated Synapse tables could become Lakehouse tables.
• Data scientists can work off the same Lakehouse via notebooks instead of pulling separate copies.

Typical pattern:

1. Land raw data in a Lakehouse (or via shortcuts to external storage).
2. Transform with Spark notebooks or Dataflows Gen2.
3. Expose curated tables to Power BI via Direct Lake or import.

Data Warehouse: SQL-Focused Analytics

Fabric’s Data Warehouse workload provides:

• A Warehouse item with SQL endpoint over tables stored in OneLake.
• T-SQL support for many common analytics operations (not identical to SQL Server; some differences in supported syntax and features).

For the BI team:

• They can keep a SQL-centric workflow for analysts who prefer T-SQL.
• The same data can be queried via SQL and used in Power BI models.

Data Factory: Pipelines and Dataflows Gen2

Fabric’s Data Factory workload combines:

• Pipelines (orchestration, similar to Azure Data Factory pipelines).
• Dataflows Gen2 (Power Query–based transformations that write to Lakehouse/Warehouse tables).

Example: a simple Dataflow Gen2 that cleans a CSV and loads into a Lakehouse table might use Power Query like:

let
    Source = Csv.Document(
        Web.Contents("https://contoso.com/data/sales.csv"),
        [Delimiter = ",", Columns = 5, Encoding = TextEncoding.Utf8, QuoteStyle = QuoteStyle.None]
    ),
    PromotedHeaders = Table.PromoteHeaders(Source, [PromoteAllScalars = true]),
    ChangedTypes = Table.TransformColumnTypes(
        PromotedHeaders,
        {
            {"OrderDate", type date},
            {"ProductId", Int64.Type},
            {"Quantity", Int64.Type},
            {"UnitPrice", type number},
            {"Region", type text}
        }
    )
in
    ChangedTypes

The output table is stored in the configured Fabric destination (e.g. Lakehouse), ready for downstream use.

Power BI and Semantic Models

Inside Fabric, Power BI is tightly integrated:

• Semantic models (formerly datasets) live in the same workspace.
• They can connect via Direct Lake, Import, or DirectQuery depending on source and design.

Example DAX measure in a semantic model over a Lakehouse table:

Total Sales :=
SUMX(
    'Sales',
    'Sales'[Quantity] * 'Sales'[UnitPrice]
)

For the BI team:

• Their existing Power BI reports can gradually move to Fabric workspaces and start using Lakehouse/Warehouse sources.

How Fabric Changes the Team’s Daily Workflow

Let’s compare the BI team’s before vs after.

Before Fabric

• Azure Data Factory pipeline lands data in ADLS Gen2.
• Synapse pipelines move data into a dedicated SQL pool.
• Power BI imports data from Synapse.
• Data scientists copy data into Databricks.
• Security and monitoring split across three services.

After Moving to Fabric

One possible Fabric design:

1. Ingest

   • Use Fabric Pipelines or Dataflows Gen2 to land data directly into a Lakehouse.
   • Use OneLake shortcuts if some data must stay in external storage.

2. Transform and Curate

   • Use Spark notebooks for heavy transformations.
   • Use Dataflows Gen2 for business-friendly, Power Query–style shaping.
   • Store curated tables in a Lakehouse or Warehouse.

3. Serve to BI and Data Science

   • Build semantic models on top of Lakehouse/Warehouse tables.
   • Use Direct Lake where suitable to reduce refresh overhead.
   • Data scientists use notebooks over the same Lakehouse.

4. Govern and Monitor

   • Use workspace roles and item permissions for access.
   • Use Fabric admin and monitoring tools to track capacity usage and performance.

Net effect:

• Fewer moving parts to coordinate.
• One data foundation (OneLake) with multiple workloads on top.
• More transparent capacity usage and cost at the tenant level.

Fabric Licensing and Pricing: What It Costs in Practice

Pricing details change over time and vary by region, so we’ll stick to structure and behaviour rather than specific numbers.

Main Components of Cost

Fabric cost typically comes from:

1. Fabric capacity (F SKUs)

   • Billed as a cloud resource (per-hour or similar model).
   • Higher SKUs have more compute and features.

2. Power BI per-user licences

   • Power BI Pro: needed for content creation and sharing in most scenarios.
   • Power BI Premium per-user (PPU): offers some advanced features but is separate from Fabric capacity.

3. Optional extras

   • Some integrations or external services may carry their own costs.

How Capacity Impacts What You Can Do

Key behaviours you need to plan around:

• Workspaces on Fabric capacity can run Fabric workloads at that capacity’s performance level.
• Workspaces not on capacity are limited; some Fabric experiences may be available in trial or limited mode, but you can’t rely on that for production.
• Capacity usage covers:
  • Lakehouse and Warehouse queries.
  • Pipelines and Dataflows Gen2 execution.
  • Notebooks and Spark jobs.
  • Power BI semantic model processing (when using Fabric capacity).

For the BI team, the cost-relevant questions are:

• Which workspaces need guaranteed performance and should be on capacity?
• How much capacity (which F SKU) is needed for their peak workloads?

Practical Cost Planning Steps

Here’s a pragmatic way to approach cost planning without guessing:

1. Inventory workloads

   • List current data volumes, refresh frequencies, and query patterns in your existing stack.

2. Map to Fabric workloads

   • For each existing job, decide whether it becomes a Pipeline, Dataflow Gen2, Notebook, Lakehouse, Warehouse, or stays external.

3. Identify critical workspaces

   • Mark the workspaces that must have predictable performance (e.g. executive reporting, regulatory data).

4. Start with a modest F SKU

   • Begin with a capacity size that you expect can handle those critical workloads.
   • Monitor capacity metrics (CPU, memory, queueing) and adjust if needed.

5. Keep some workloads off capacity initially

   • Development, experiments, and low-priority reports can stay off capacity or on smaller capacities.

This approach lets the team avoid overbuying while still giving production workloads a stable environment.

When Fabric Makes Sense (and When It Doesn’t)

Fabric tends to be useful when:

• You already have a multi-service Azure analytics stack and want to simplify it.
• You need closer integration between data engineering, data science, and BI.
• You care about centralizing governance, lineage, and monitoring.

It may be less compelling when:

• Your needs are small and well served by standalone Power BI Pro with simple data sources.
• You have heavy investments in non-Microsoft data platforms that won’t integrate easily.

For our BI team, Fabric is most attractive if:

• They can retire or consolidate some of their existing services.
• They can get clearer cost visibility via Fabric capacity monitoring.

A Concrete Next Step: Design One Fabric Workspace

Rather than debating Fabric in the abstract, pick one domain and design a single Fabric workspace end-to-end:

• Define the Lakehouse or Warehouse structure for that domain.
• Decide which data lands via Pipelines vs Dataflows Gen2.
• Map existing Power BI reports to semantic models in that workspace.
• Assign that workspace to a Fabric capacity and monitor usage for a few weeks.

That one workspace will give you real data on performance, cost, and team workflow changes. From there, you can decide whether Fabric is just another tool, or the new backbone of your analytics stack.