Modernizing Your Data Stack with Microsoft Fabric

Microsoft Fabric: Disruption or Rebrand?

Since its announcement at Build 2023, Microsoft Fabric has divided data teams. Some see it as an Azure Synapse rebrand. That reading is too narrow. Fabric is an architectural shift: where Synapse required orchestrating several distinct services (Data Factory, Synapse Analytics, Power BI Premium), Fabric integrates them into a unified experience with a shared storage layer, OneLake.

After guiding several organizations through Fabric adoption, here is a production-based assessment: real strengths, pitfalls to avoid, and how to structure a medallion architecture that holds up.

OneLake: The Fundamental Change

Before Fabric, a typical Azure data stack looked like this: Azure Data Lake Storage Gen2 for raw storage, Azure Data Factory for pipelines, Synapse or Databricks for transformation, Power BI Premium layered on top. Each service had its own storage account, managed identities, and separate costs.

Fabric changes this model. Everything lives in OneLake, a single hierarchical data lake per tenant. A Parquet file written by a Spark notebook is immediately accessible in Power BI through a Semantic Model, with no copy, no movement, no intermediate pipeline.

This storage model shift is what makes Fabric compelling, not the UI.

Medallion Architecture on Fabric

The medallion architecture (Bronze, Silver, Gold) remains the reference for organizing data in a lakehouse. Fabric supports it natively through Lakehouses.

Bronze Layer: Raw Ingestion

Data Factory pipelines integrated in Fabric handle ingestion. We configure append-only ingestion to Bronze Delta tables. Nothing is overwritten; everything is versioned. One caveat: Fabric Data Factory does not yet have full parity with Azure Data Factory v2. Specific connectors (SAP, legacy APIs) still require classic ADF pipelines connected via OneLake Shortcuts.

Silver Layer: Cleansing and Conformance

The Silver layer is processed by Spark notebooks. We consistently apply three rules:

Gold Layer: Business Models

The Gold layer exposes data as business-oriented tables. Complex joins and heavy aggregations are computed once here, not repeated in every report. Gold tables are directly consumed by Power BI Semantic Models via Direct Lake.

Power BI Semantic Models: The Keystone

The Semantic Model (formerly Power BI Dataset) is the most underestimated element in a Fabric architecture. It defines DAX measures, hierarchies, relationships, and row-level security (RLS).

Direct Lake: Real Advantages and Real Limits

Direct Lake is the native connection mode between Fabric and Power BI. It avoids importing data into the Vertipaq engine and provides fresh data without scheduling refreshes.

In practice, Direct Lake has known limits:

Our approach: Direct Lake for high-volume operational dashboards, classic Import for analytical reports with complex DAX models.

Shared Semantic Model Architecture

A Semantic Model should not be a black box. We consistently structure two tiers:

This pattern prevents model proliferation and ensures metric consistency across teams. All DAX measures are documented with descriptions visible in Power BI Desktop.

RLS Governance

RLS is tested with representative user profiles before every release. We connect Azure AD groups via SCIM so licenses are automatically assigned based on AD group membership. A user who leaves the organization loses Fabric access within minutes of their Active Directory deactivation.

OneLake Shortcuts: Progressive Migration

OneLake Shortcuts let you point to data in Azure Data Lake Storage Gen2 or Databricks without physically copying it. This is the clean way to migrate to Fabric progressively without breaking existing pipelines. We use them as a transition bridge: data stays in its original location during migration, and the switch to native OneLake happens domain by domain.

When to Adopt Fabric

Fabric is the right choice if your organization is already in the Microsoft ecosystem (Azure, M365, Power BI) and you want to reduce operational complexity by consolidating your data services.

Fabric is likely the wrong choice if your stack is heavily open-source oriented (dbt, Airflow, standalone Spark) or if you have advanced ML requirements where Databricks remains superior.

The platform is maturing fast. What was missing 18 months ago is often available today.