Power BI Fabric Integration: Complete Enterprise Guide
Microsoft Fabric, generally available since November 2023, is Microsoft's SaaS analytics platform. It brings Power BI together with data integration, data engineering, data warehousing, data science and real-time analytics experiences on shared capacity and a single data lake. For Power BI customers, the most consequential parts are Direct Lake mode and the underlying OneLake storage layer, which together change how Power BI reads data, how capacity is consumed, and how semantic models are shared across an enterprise.
This guide explains how Power BI fits inside Fabric, what changed with Direct Lake, and what teams should consider when moving off the retiring Power BI Premium capacity SKUs or building new Fabric deployments.
Power BI is one of the workloads inside Microsoft Fabric. The two key pieces are OneLake (one data lake per tenant that stores tables in open Delta Parquet format, also readable as Iceberg) and Direct Lake mode (a semantic model loads columns from Delta tables in OneLake on demand, with query performance comparable to Import mode and no full data import). Fabric capacities (F SKUs) are shared by all Fabric workloads. Microsoft is retiring the Power BI Premium per-capacity P SKUs, so Premium customers buy an F SKU and reassign their workspaces; reports and semantic models keep working, and Pro and Premium Per User licenses are not affected. Direct Lake requires the data to live in Delta tables in OneLake.
Power BI in Fabric
Before Fabric, Power BI was a standalone product with its own pricing tiers (Pro, Premium Per User, Premium capacity) and its own runtime. Reports lived in workspaces; data either lived in Import mode (loaded into Power BI's VertiPaq engine) or in DirectQuery mode (queries pushed to the source on every interaction).
With Fabric, Power BI runs on the same capacity as the other Fabric workloads, typically an F SKU bought through Azure. Power BI Desktop and the Power BI service remain the everyday tools, but underneath, capacity, storage, and semantic-model architecture have been substantially restructured.
How Power BI Fits in Fabric
Fabric introduces a tenant-wide architecture with several roles for Power BI assets:
The four layers from bottom up:
- OneLake - one data lake per tenant, built on Azure Data Lake Storage. The Fabric engines store their tables here in the open Delta Parquet format.
- Data items - Lakehouses (Spark + Delta), Warehouses (T-SQL), Eventhouses (KQL/Kusto). Lakehouses and Warehouses keep their tables in OneLake; an Eventhouse makes its data available there when OneLake availability is turned on.
- Semantic models - formerly "Power BI datasets". Define tables, relationships, and DAX measures. Connect to underlying data via Direct Lake, Import, DirectQuery, or composite mode.
- Reports and tools - Power BI reports, paginated reports, Excel pivot tables, notebooks, Copilot, and third-party tools that connect through the XMLA endpoint.
Direct Lake Mode Explained
Direct Lake is the biggest change to Power BI's storage modes in years. Before Fabric, Power BI engineers had to choose between two trade-offs:
- Import mode - copy data into Power BI's VertiPaq columnar engine. Fast queries, but data is stale until the next refresh, and large datasets hit storage and refresh-time limits.
- DirectQuery mode - push every query down to the source. Always fresh, but every dashboard interaction triggers a database query, and performance is bounded by the source.
Direct Lake is a third storage mode, built for large Delta tables in OneLake:
- When a query needs a column that is not yet in memory, the semantic model loads that whole column from the Delta table's Parquet files in OneLake, a process Microsoft calls transcoding. There is no Import-style copy of the full data volume.
- Queries are processed by the same VertiPaq engine as Import mode, so query performance is comparable to Import.
- A Direct Lake refresh, called framing, copies only metadata and points the model at the latest version of each Delta table, which usually takes seconds. With automatic updates turned on (the default), the model reframes whenever the underlying Delta tables change.
Delta tables are stored as columnar Parquet files, which is why loading individual columns into VertiPaq's columnar memory is cheap compared with a full import. The model holds the metadata (tables, relationships, measures); the column data is loaded from OneLake as queries need it and can be evicted again under memory pressure or after framing.
Direct Lake comes in two variants with different limits. Direct Lake on SQL analytics endpoints falls back to DirectQuery, which is slower, when it cannot read a Delta table directly: for tables based on SQL views, tables with row-level or object-level security defined in the SQL analytics endpoint, or tables that exceed the capacity's guardrails. Under the default Direct Lake behavior setting (Automatic), that fallback is silent. Direct Lake on OneLake, which Microsoft recommends for new models, never falls back; a refresh or query that cannot run in Direct Lake fails instead. It can also be combined with Import tables in one model. Calculated columns and tables that reference Direct Lake tables are restricted, so derived columns usually belong in the lakehouse.
OneLake Foundation
OneLake is the storage layer that makes the Fabric integration work. Every Fabric tenant automatically includes exactly one OneLake, built on Azure Data Lake Storage, and it works with ADLS-compatible APIs that address data by workspace and item (https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>.<itemtype>/...).
Two OneLake features matter most for Power BI users:
- Shortcuts - references to data in another OneLake location or in external storage such as Azure Data Lake Storage, Amazon S3 and S3-compatible storage, Iceberg-compatible sources or Microsoft Dataverse, without copying it. A Power BI semantic model in one workspace can use a Delta table physically stored in another team's lakehouse, or in another cloud, through a shortcut. This is the core mechanism for sharing data across Fabric workspaces without duplicating it.
- Iceberg interoperability - OneLake generates virtual metadata so that Apache Iceberg tables can be read as Delta tables by Fabric engines, and Delta tables in OneLake can be read by Iceberg-compatible services such as Snowflake.
Semantic Models in Fabric
Power BI's "datasets" were renamed semantic models in November 2023. Microsoft describes it as a rename only, with no change in behavior, but the new name reflects the role these models now play as a shared, governed layer reused across many tools.
A semantic model in Fabric:
- Defines tables, columns, relationships, hierarchies, and DAX measures.
- Connects to OneLake data via Direct Lake, or to external sources via DirectQuery / Import.
- Is consumed by Power BI reports, Excel, paginated reports, notebooks, custom apps via XMLA, Copilot, and third-party tools through the same XMLA endpoint.
- Inherits workspace access and can define its own row-level and object-level security; Microsoft Purview adds sensitivity labels and data loss prevention policies.
For deeper modeling guidance, see Power BI Data Modeling.
Workspaces and Sharing
Fabric workspaces hold all artifacts - lakehouses, warehouses, semantic models, reports, dashboards. Within a workspace:
- All items use the capacity the workspace is assigned to, and their data lives in OneLake.
- Access is granted through four workspace roles (Admin, Member, Contributor, and Viewer), and individual items can be shared with item-level permissions such as ReadData and ReadAll on lakehouse data.
- Apps package selected reports and dashboards for end-user distribution, hiding the underlying complexity.
Cross-workspace sharing happens through OneLake shortcuts, endorsement (Promoted, Certified, and Master data), and Power BI app distribution. The semantic-model-as-shared-asset pattern is the recommended approach for organizations that previously had dozens of duplicated dataset copies across different reports.
Performance Considerations
- DirectQuery fallback - with Direct Lake on SQL analytics endpoints, tables based on SQL views, tables with SQL-level security, and tables beyond the guardrails send their queries to the SQL analytics endpoint instead, which is slower. The DAX query
EVALUATE TABLETRAITS()shows the fallback reason for each table, and Performance Analyzer or SQL Server Profiler show it per query. During development, setting the Direct Lake behavior to DirectLakeOnly turns silent fallback into an error. - Capacity sizing - Fabric F SKUs share capacity across all workloads, so heavy Spark jobs and intensive Power BI use compete for the same capacity units (CUs). Bursting lets an operation temporarily use more compute than the SKU provides, and smoothing spreads its cost over time (interactive operations over at least five minutes, background operations over 24 hours). Throttling starts once the capacity has used up its next 10 minutes of CUs, so sizing must consider all workloads, not just Power BI.
- Cold cache - Direct Lake loads a column into memory the first time a query needs it, and framing can evict columns whose data changed, so the first queries after a refresh can be slower than later ones. Running representative queries after a refresh warms the model.
- Delta file layout - the guardrails cap Parquet files and row groups per table by SKU (for example 1,000 Parquet files per table on F2 to F32 and 5,000 on F64), and Direct Lake performance depends on well-tuned Delta tables. Compact tables with
OPTIMIZE, and consider V-Order, a Fabric write-time Parquet optimization for read-heavy workloads that is compatible with Z-Order.
Migration from Power BI Premium
Microsoft is retiring the Power BI Premium per-capacity SKUs (P SKUs). It no longer sells new P SKUs, and each P SKU subscription ends at the end of its current agreement term; Enterprise Agreement customers can keep renewing existing P capacity until their agreement ends. Migration is a licensing and infrastructure change, and it is not automatic:
- P SKU to F SKU - buy an F SKU, reassign workspaces to it, then cancel the P SKU manually. Microsoft's SKU table lines up P1 with F64 (64 CUs, 8 v-cores) as a compute reference, not as a statement of licensing equivalence. Reports, semantic models, and dashboards continue to work unchanged on F64 or larger. After a P SKU subscription ends there is a 30-day grace period, then throttling, and from day 91 all operations are rejected until the workspaces move.
- Viewer licensing - on F64 and larger, users with a free license and the Viewer role can view Power BI content, as on P SKUs. On F2 to F32, every viewer needs a Pro or Premium Per User license.
- Pro and Premium Per User are not affected by the retirement and continue as license tiers.
- New features (Direct Lake, OneLake shortcuts, Eventhouse) require data to live in Fabric items. Existing Import and DirectQuery models keep working; Microsoft treats the Fabric features as optional modernization after the licensing move, not as part of it.
The bigger migration is operational. Capacity is now consumed by Spark notebooks, warehouse queries, real-time analytics, and Power BI together - a Power BI capacity that was comfortably sized in 2023 may be tight in 2026 if other Fabric workloads have moved into the same tenant.
Best Practices
- Default to Direct Lake when the data is already in Delta tables in OneLake, and prefer Direct Lake on OneLake for new models. Keep Import for self-service models whose authors cannot change the lakehouse.
- Watch for fallback. On Direct Lake on SQL analytics endpoints, check
TABLETRAITS()regularly and fix the causes: materialize views as Delta tables, move SQL-level security into the semantic model, and compact tables that exceed the guardrails. - Optimize Delta files. V-Order is disabled by default in new Fabric workspaces, so turn it on (or use a read-heavy resource profile) for tables that feed Direct Lake, and run
OPTIMIZEon tables with frequent appends. - Treat semantic models as shared assets. Endorse them, version them with Git integration, document them in business glossary terms.
- Monitor capacity holistically. The Microsoft Fabric Capacity Metrics app shows CU consumption and throttling across all workloads, so a bottleneck that surfaces in a report may come from a Spark or warehouse job.
- Combine Fabric governance with Purview. Fabric's built-in governance (the OneLake catalog, endorsement, domains, and lineage across Fabric items) is the starting point; Microsoft Purview adds sensitivity labels, data loss prevention, and audit.
Power BI inside Fabric is a more capable platform than Power BI Premium ever was. The cost is operational complexity - capacity now serves many workloads, semantic models are more central, and Direct Lake performance depends on lakehouse hygiene. Teams that adopted Power BI primarily for self-service BI will find the new world more powerful, but it asks more of the data engineering side of the house.
Sources
- Microsoft, Prepare your data for AI innovation with Microsoft Fabric, now generally available (15 November 2023).
- Microsoft Learn, OneLake, the unified data lake.
- Microsoft Learn, How do I connect to OneLake?
- Microsoft Learn, Direct Lake overview (storage modes, guardrails per SKU, limitations).
- Microsoft Learn, How Direct Lake works (transcoding, framing, automatic updates, DirectQuery fallback).
- Microsoft Learn, New name for Power BI datasets.
- Microsoft Learn, Roles in workspaces in Microsoft Fabric.
- Microsoft Learn, Endorsement overview.
- Microsoft Learn, Understand capacity throttling and smoothing.
- Microsoft Learn, Optimize Delta Lake tables with V-Order in Fabric.
- Microsoft Learn, Understand Microsoft Fabric licenses and capacity.
- Microsoft Learn, Power BI Premium to Microsoft Fabric Migration Overview.
- Microsoft Learn, Use Microsoft Purview with Microsoft Fabric.
See it in action
Data & Analytics Catalog
Create a unified view of your data assets and gain insights faster with automated data discovery.