Power BI and Microsoft Fabric: Native Integration, DirectLake Mode, and What Changes for BI Teams

Before Microsoft Fabric, operating Power BI at enterprise scale meant navigating a set of trade-offs that never fully resolved. Import mode delivered fast report performance but created stale data windows — the dashboard your CFO looked at at 9 AM reflected data from the 3 AM refresh, not the 8:45 AM transactions. DirectQuery mode delivered live data but hit SQL endpoints for every visual render, making complex reports with multiple visuals painfully slow on large tables. Composite models helped at the margins but added governance complexity.

For BI teams supporting reporting on datasets in the millions to billions of row range, neither option was fully satisfying. DirectLake mode in Microsoft Fabric changes that trade-off — and understanding precisely how it works explains why Power BI’s integration with Fabric is not just a convenience feature but an architectural advance.

What Changed When Power BI Became a Fabric Workload

Before Fabric, Power BI was a SaaS service connected to Azure analytics infrastructure via connectors. A Power BI Premium workspace connected to Azure Synapse Analytics via a Synapse Link connector, or to ADLS Gen2 via a Power Query M query, or to Azure Analysis Services via a live connection. Each connector was a boundary: credentials to manage, refresh schedules to configure, latency to tolerate.

In Fabric, Power BI is a first-class workload — not a connected external service but a native participant in the Fabric workspace model. Power BI items (semantic models, reports, dashboards) live in the same workspace as Lakehouses, Notebooks, and Pipelines. They share OneLake storage through DirectLake. Permissions propagate from OneLake through the semantic model to the report — a user’s access level in Fabric determines what data they see in the Power BI report without additional configuration.

DirectLake Mode Explained

DirectLake is a query mode available to Power BI semantic models in Fabric. Instead of importing data into the Analysis Services engine (import mode) or querying a SQL endpoint at report-render time (DirectQuery), DirectLake reads Delta Parquet files directly from OneLake.

The technical mechanism works like this: when you first open a DirectLake report after data has changed in the underlying Delta table, the Power BI engine reads the Delta table’s metadata files, identifies which Parquet files contain the current data, and loads column segments into memory on demand. This process is fast — significantly faster than a full import refresh — because it reads only the column segments required for the current query, not the entire dataset.

Once column segments are loaded into the Analysis Services in-memory engine, query performance is equivalent to import mode. The difference is that the data is current: DirectLake reflects the state of the Delta table at the time of the query, not the time of the last scheduled import.

When DirectLake falls back to DirectQuery: If a DirectLake query requires data that is not yet loaded into memory, or if the Analysis Services engine determines that the query pattern would be more efficiently served by the SQL analytics endpoint, it can fall back to DirectQuery against the Lakehouse SQL endpoint. This fallback is automatic and transparent to the report consumer, though it introduces the latency characteristic of DirectQuery for that specific query.

DirectLake vs Import vs DirectQuery: A Practical Comparison

Mode	Data Freshness	Query Performance	Dataset Size Limit	Operational Complexity
Import	Stale (last refresh)	Fastest (in-memory)	Premium capacity limit	High (refresh schedules, gateways)
DirectQuery	Live	Slowest (SQL round-trip)	Unlimited	Moderate (SQL endpoint tuning)
DirectLake	Near-real-time	Fast (in-memory after load)	OneLake scale	Low (no refresh schedule)

DirectLake’s “near-real-time” freshness reflects the fact that data is available as soon as the Delta table write commits to OneLake — which for a streaming Eventstream pipeline could be seconds; for a nightly Spark batch job, it would be available immediately after the job completes.

Semantic Models in Fabric: One Model, Multiple Reports

A semantic model in Fabric (formerly called a Power BI dataset) is the business logic layer between raw Delta tables and end-user reports. It defines:

• Relationships between tables
• DAX measures (revenue calculations, KPIs, period-over-period comparisons)
• Row-level security rules (who sees which rows)
• Column metadata (display names, formatting, description)

The recommended Fabric architecture pattern places a single semantic model over the Gold Lakehouse layer, with multiple reports connecting to that model. This separation means:

• Business logic is defined once in the semantic model, not duplicated across reports
• Changes to a measure (adjusting the revenue calculation, updating an exchange rate) propagate automatically to all connected reports
• Row-level security is enforced at the semantic model layer, consistently across all reports

For Fabric-native semantic models in DirectLake mode, the model connects directly to Delta tables in a Lakehouse. You specify which tables to include in the model; Fabric generates the initial schema automatically.

Deployment Pipelines: Dev → Test → Prod for Power BI

Fabric workspaces support deployment pipelines — a mechanism for promoting Power BI content (and other Fabric items) through dev, test, and production environments. A deployment pipeline assigns three workspaces to three stages; you promote items from dev to test to prod through the pipeline UI, with optional automated validation rules.

For BI teams that have historically managed Power BI deployment through PBIX file exports, manual uploads, and undocumented workspace structures, deployment pipelines provide a meaningful process improvement. Combined with Git integration for Fabric workspaces (which allows committing workspace item definitions to a Git repository), this brings Power BI closer to a software development lifecycle discipline.

Copilot in Power BI (Fabric): What’s Actually Useful

Copilot in Power BI, available in Fabric F64 and above capacities (and Power BI Premium), provides several AI-assisted capabilities:

Narrative visuals: A text visual that generates a natural-language summary of the data visible in the current report context. The generated text updates when report filters change. Useful for executive summaries on dashboards; not a replacement for analyst commentary on nuanced data.

Q&A improvements: The natural language Q&A visual — which existed before Copilot — is improved with Copilot’s language understanding. Users can ask “Show me revenue by region for last quarter compared to the same period last year” and receive a recommended visual. Works well for simple to moderate queries; struggles with multi-step analytical questions.

Measure suggestions: In the semantic model authoring experience, Copilot suggests DAX measures based on the model structure and prompt descriptions. Useful for accelerating measure creation for standard patterns (year-over-year, running totals, moving averages). Requires review — generated DAX should be validated for correctness before publishing.

Report generation from description: Given a description and a semantic model, Copilot can generate a report page with appropriate visuals. Output quality varies significantly with model quality and description specificity. Best used as a starting point for rapid prototyping, not production report delivery.

Honest assessment: Copilot in Power BI is a useful productivity tool for BI developers, particularly for accelerating measure authoring and initial report scaffolding. It is not yet a replacement for Power BI skills, and it requires thoughtful review of all generated output before use in decision-support contexts.

AWS Equivalent: Power BI + Fabric vs Amazon QuickSight

For teams evaluating between an AWS-native and Microsoft-native analytics stack, the BI comparison is significant:

Amazon QuickSight is a fully managed, serverless BI service. It is simpler to operate than Power BI at small scale and has competitive pricing ($18/user/month for authors at time of writing). SPICE — QuickSight’s in-memory engine — provides fast queries on imported data.

Where Power BI + Fabric wins: DirectLake’s near-real-time freshness with in-memory performance is a genuine technical advance that QuickSight’s SPICE model does not offer. Power BI’s semantic model layer with DAX provides significantly more powerful business logic capabilities than QuickSight’s calculated field model. Power BI’s report authoring is more flexible for complex layout requirements.

Where QuickSight is simpler: QuickSight’s ML Insights (anomaly detection, forecasting) are built-in without requiring Copilot licensing. QuickSight’s pricing model is more straightforward for organisations without existing Microsoft agreements. For AWS-native organisations with Redshift or Athena as the analytical SQL layer, QuickSight’s native connectors require no platform context-switching.

The decision typically follows the cloud platform decision: AWS-native organisations use QuickSight; Microsoft-ecosystem organisations use Power BI. Fabric’s contribution is making Power BI dramatically more capable for large datasets through DirectLake — which removes one of the primary technical objections to Power BI at enterprise scale.

What Actually Changes for BI Teams Adopting Fabric

For Power BI teams migrating from a pre-Fabric environment, the operational changes are:

1. No more scheduled dataset refreshes for DirectLake models. The primary scheduled maintenance task for most Power BI datasets — refresh scheduling, monitoring, failure alerts — is eliminated for datasets in DirectLake mode.

2. Workspace reorganisation. Fabric workspaces contain a mix of Fabric items (Lakehouses, Notebooks) and Power BI items (semantic models, reports). BI teams need to understand the workspace model and collaborate with data engineering teams who share the same workspace.

3. Semantic model authoring in Fabric portal. The Fabric web portal becomes the primary authoring environment for DirectLake semantic models. Power BI Desktop can still be used for report authoring but is not required for model creation in Fabric.

4. Deployment pipeline discipline. The deployment pipeline model encourages (and in some organisational configurations, requires) formalising the dev → test → prod promotion process.

See our post on the OneLake architecture guide for the storage model that underlies DirectLake.

Conclusion

Power BI’s native integration with Microsoft Fabric through DirectLake mode is the most practically significant change in enterprise BI architecture for Microsoft-aligned organisations in the past several years. Eliminating the import/DirectQuery trade-off removes the primary operational burden of running Power BI at scale on large, fast-changing datasets.

Evaluating Microsoft Fabric for your organisation? Infra IT Consulting helps Canadian and international businesses assess, architect, and implement modern data platforms. Book a discovery call →