Power BI Direct Query vs Import Mode: Which to Choose?

When you connect data in Power BI, choosing between Power BI Import Mode vs Direct Query is one of the first — and most consequential — decisions you will make. However, with Microsoft Fabric’s growing adoption, there is now a third option that changes the equation entirely: Direct Lake mode. In this guide, I compare all three storage modes side by side so you can choose the right one for your project.

After six years working on Power BI implementations, I still use Import Mode in the vast majority of my projects. However, I have worked with Direct Query in Composite Models and have been exploring Direct Lake in Fabric environments. Consequently, I can give you a practical take — not just the official documentation summary. Read to the end to see why I still recommend Import Mode in 99% of cases, and specifically when Direct Lake becomes the clear winner.

Power BI Import Mode vs Direct Query vs Direct Lake: At a Glance

Below is a high-level comparison of all three storage modes. Additionally, I have added Direct Lake to the original two-mode table because it changes the decision significantly for teams working in Microsoft Fabric.

“For most Power BI developers, Import Mode remains the right default. However, if your organisation is moving to Microsoft Fabric and working with large datasets, Direct Lake changes the equation entirely — it is specifically designed for that environment.”

What Is Import Mode in Power BI?

Import Mode in Power BI copies your entire dataset from the source into Power BI’s in-memory VertiPaq engine at refresh time. All subsequent report interactions run against the cached data rather than the original source. As a result, reports are fast and consistent regardless of how complex or slow your data source is.

Import Mode — Definition

Import Mode: A Power BI data connectivity mode in which the full dataset is extracted from the source and stored in Power BI’s in-memory columnar engine (VertiPaq). Consequently, all queries run against the cached copy — not the original data source — until the next scheduled refresh.

Key Benefits of Import Mode

• Fastest report performance: Because data is fully cached, visuals render near-instantaneously — even on complex data models with millions of rows.
• Full DAX support: Additionally, every DAX function works without restriction — including time intelligence, PATH, CALCULATE with complex filters, and row-level context calculations.
• Complete modeling flexibility: You can create calculated columns, calculated tables, and complex relationships. Furthermore, all Power Query M transformations are available without limitation.
• Works with all data sources: Import Mode is compatible with every source Power BI supports — databases, files, APIs, cloud connectors, and everything in between.
• Offline access: Moreover, once data is imported, reports work without a live connection to the source system.

Limitations of Import Mode

• Dataset size cap: Power BI Pro limits datasets to 1 GB compressed. However, Power BI Premium and Microsoft Fabric capacity lift this significantly — up to 25 GB or more depending on the SKU.
• Scheduled refreshes only: Data is only as current as the last successful refresh. Consequently, real-time or near-real-time use cases are not a good fit for pure Import Mode.
• Refresh frequency limits: Power BI Pro allows up to 8 scheduled refreshes per day. Additionally, each refresh reloads the entire dataset — which can be slow for large models and consumes compute resources.

When to Use Import Mode

Import Mode is the right choice when you need fast, reliable reports and your data does not change faster than your refresh schedule allows. In my experience, this describes the overwhelming majority of Power BI projects — financial dashboards, sales reports, operational analytics, HR reporting, and similar use cases all work exceptionally well with Import Mode.

If you want to deepen your Power BI modeling knowledge — including storage modes, DAX, and star schema design — I have reviewed the available DataCamp Power BI courses to help you decide whether their structured learning path is worth it.

What Is Direct Query Mode in Power BI?

Direct Query Mode in Power BI sends a live query to your data source every time a report visual is interacted with. As a result, reports always reflect the current state of the data in the source system. However, this comes at the cost of report speed — every click, slicer change, or filter triggers a new real-time query against your database.

Direct Query Mode — Definition

Direct Query Mode: A Power BI connectivity mode in which no data is stored in Power BI’s memory. Instead, every report interaction sends a live SQL query to the connected data source. Only the schema and metadata are stored locally in the .pbix or .pbip file.

Key Benefits of Direct Query Mode

• Always-current data: Because reports query the source directly, there is no lag between source changes and what users see. For live operations dashboards, this is essential.
• No dataset size limit: Since data stays in the source, there is no 1 GB ceiling. Consequently, it works for very large transactional databases that would never fit in Power BI’s memory.
• Data sovereignty compliance: Furthermore, for organisations with policies requiring data to remain on-premises or in a specific cloud environment, Direct Query avoids replication entirely.

Limitations of Direct Query Mode

• Performance depends on your source: Report speed is entirely determined by the data source and network. Slow or poorly indexed databases lead to a frustrating user experience.
• Restricted DAX functions: Certain functions — including PATH, some uses of DATEADD, and several advanced aggregations — are either unsupported or behave differently in Direct Query mode. Refer to Microsoft’s official Direct Query documentation for the full limitations list.
• No calculated columns or tables: Additionally, you cannot create calculated columns or calculated tables — these must be built at the source level in SQL or a transformation layer.
• No Data View: The Data View tab in Power BI Desktop is unavailable in Direct Query mode, which makes it harder to inspect and validate your data during development.
• 1-million-row limit per visual: Moreover, each visual is limited to 1 million rows per query. Very large result sets must be aggregated at the source before reaching Power BI.

When to Use Direct Query Mode

Direct Query is the right choice when data freshness cannot be compromised — for example, live operations dashboards, fraud detection systems, or any scenario where a one-hour data lag is unacceptable. It is also appropriate when your dataset is too large for Import Mode and you are not yet working in a Microsoft Fabric environment. Specifically, if you have an existing SQL Server or Azure SQL database that is well-indexed and tuned, Direct Query is a viable path without requiring infrastructure changes.

Development Tip: Pause Visual Queries in Direct Query Mode

When developing with Direct Query, every model change triggers a live source query — which can dramatically slow your workflow, especially with large or complex databases. To work around this, go to the Optimize tab in Power BI Desktop and click “Pause Visual Queries.” While paused, you can build, edit, and iterate on your model without triggering data queries. Once you are ready to validate, click “Resume Visual Queries” to refresh all visuals at once. In my experience, this single habit makes Direct Query development significantly more efficient.

What Is Direct Lake Mode in Power BI?

Direct Lake mode is a Power BI storage mode exclusive to Microsoft Fabric that reads Parquet files directly from OneLake — without copying data into memory and without sending a live query to the source on every visual interaction. In other words, it attempts to combine the best of Import Mode (speed) and Direct Query (freshness) into a single mode. However, it comes with meaningful constraints that matter in practice.

Direct Lake Mode — Definition

Direct Lake Mode: A Power BI storage mode available exclusively in Microsoft Fabric that reads Delta Lake Parquet files directly from OneLake. As a result, it achieves near-Import query performance without duplicating data into Power BI’s in-memory engine, and without the per-interaction latency of Direct Query mode.

How Direct Lake Works

In a traditional Import setup, Power BI compresses your data and loads it into the VertiPaq in-memory engine at refresh time. In contrast, Direct Lake reads the Parquet column files that already exist in OneLake — the unified storage layer underlying all Microsoft Fabric workloads. Consequently, when a user interacts with a report, Power BI reads the relevant column segments directly from OneLake rather than relying on a pre-loaded memory cache or sending a live SQL query.

The practical result: data reflects whatever is currently in OneLake — effectively always fresh — and query performance is close to Import Mode speed for most workloads. Furthermore, there is no scheduled refresh to manage. Power BI automatically reads the latest version of the data as it changes in OneLake.

Benefits of Direct Lake Mode

• Near-Import query performance: Because it reads from optimised Parquet column files in OneLake, query speed is close to a fully cached Import model for most workloads.
• Always-fresh data without a refresh schedule: Additionally, there is no explicit refresh step — the semantic model reads the latest data in OneLake automatically as it is updated by pipelines or Spark notebooks.
• No data duplication: Data remains in OneLake in open Delta Lake format. Consequently, you avoid the memory overhead and dataset size cap of Import Mode.
• Designed for scale: Moreover, Direct Lake is specifically built for enterprise Fabric deployments where Import would be impractical due to dataset size and Direct Query would be too slow for good user experience.

Limitations and Caveats of Direct Lake Mode

1. Requires Microsoft Fabric Capacity — Not Available with Power BI Pro

Direct Lake is not available with a standard Power BI Pro license or a standard Premium Per User (PPU) workspace. You specifically need a Microsoft Fabric capacity (F SKU) assigned to your workspace. Consequently, if your organisation has not adopted Fabric, Direct Lake is simply not an option at this point. For a full breakdown of what Fabric means for Power BI developers, see my guide on Power BI vs Microsoft Fabric.

2. Only Works with Fabric-Native Sources — Not Traditional SQL Databases

This is the most important limitation to understand: Direct Lake only connects to Fabric data sources backed by Delta tables in OneLake. Specifically, it supports Fabric Lakehouse, Fabric Data Warehouse, Fabric SQL Database, and mirrored databases. It does not work with SQL Server, Azure SQL Database, Oracle, SAP HANA, or any other traditional relational database outside of Fabric. As a result, Direct Lake requires your data to first land in OneLake — typically via Spark notebooks, Microsoft Data Factory pipelines, or Fabric dataflows — before the semantic model can read it.

Microsoft now also distinguishes between two variants: Direct Lake on OneLake, which can connect to multiple Fabric sources simultaneously and never falls back to Direct Query mode, and Direct Lake on SQL endpoints, which is limited to a single Fabric data source and may fall back to Direct Query when encountering SQL views or certain access control configurations. For most use cases, Direct Lake on OneLake is the preferred and more capable option.

3. No Calculated Columns on Direct Lake Tables

You cannot create calculated columns on tables that use Direct Lake storage. For Power BI developers accustomed to building calculated columns in the semantic model, this is a meaningful limitation. However, you can still create DAX measures, and you can add calculated columns on disconnected Import-mode tables within the same Composite model. The recommended approach is to perform column-level calculations at the lakehouse layer in SQL or Spark before the data reaches the semantic model.

4. XMLA Endpoints and Modeling Tool Limitations

XMLA read-write endpoints must be enabled on your Fabric capacity for Direct Lake to function. Furthermore, tools that rely on XMLA write access — such as Tabular Editor — have reduced functionality with Direct Lake models. Specifically, you cannot use these tools to create calculated columns on Direct Lake tables, as the engine enforces the same restriction regardless of the tooling used. Additionally, external modeling tools that connect via the Analysis Services engine behave differently with Direct Lake semantic models compared to standard Import-mode models.

5. Automatic Fallback to Direct Query (Framing)

When a Direct Lake query requires more columns than your Fabric capacity SKU allows in a single operation, Power BI automatically falls back to Direct Query mode to serve that result. This behaviour is called framing. As a result, certain complex or wide queries on lower-tier Fabric SKUs may behave more like Direct Query than Direct Lake — with the associated per-interaction latency. Monitoring fallback frequency is therefore important for performance-sensitive deployments.

When to Use Direct Lake Mode

Direct Lake is the right choice when you are operating in a Microsoft Fabric environment with Fabric capacity assigned, your data is already stored in a Fabric Lakehouse or Data Warehouse, your dataset is too large for Import Mode, and you need fresher data than a scheduled refresh provides. In other words, it is purpose-built for the enterprise Fabric use case. For most standalone Power BI Pro projects, Import Mode remains the simpler, more flexible choice.

How Each Mode Works — Technical Comparison

Understanding the technical difference between these three modes clarifies why they perform so differently. Specifically, the distinction comes down to where data lives and how queries are resolved at runtime.

Import Mode — Technical Behaviour

In Import Mode, Power BI extracts your data at refresh time, compresses it using the VertiPaq columnar engine, and loads it entirely into memory. As a result, all DAX queries execute in-process against the in-memory model — which is why performance is so consistently fast. However, this requires periodic refreshes to stay current, and the dataset is constrained by available memory on the capacity.

Direct Query Mode — Technical Behaviour

In Direct Query mode, Power BI stores only the schema and metadata. Every time a visual renders or a slicer changes, Power BI translates the DAX measure into a native SQL query — or the equivalent for non-SQL sources — and sends it to the source system. Consequently, every interaction is network-bound and database-bound. Performance depends entirely on how quickly the source can return results and how well the underlying tables are indexed and partitioned.

Direct Lake Mode — Technical Behaviour

Direct Lake reads Parquet column files directly from OneLake using the Fabric runtime. Rather than loading all data into memory or querying the source per interaction, it performs “hot reads” on the relevant Parquet segments at query time. In effect, it functions like a very large in-memory cache that does not require an explicit load step. Furthermore, because OneLake stores data in open Delta Lake format, the same data is simultaneously readable by Spark, SQL endpoints, and Power BI — without any duplication across systems.

Supported Data Sources by Storage Mode

Not every data source is compatible with every storage mode. Specifically, both Direct Query and Direct Lake impose significant restrictions on which sources they support. The table below summarises compatibility for the most commonly used sources.

For a complete and up-to-date list of Direct Query-compatible sources, refer to Microsoft’s official Power BI data sources documentation.

Power BI Import vs Direct Query: Which Mode Should You Use?

The correct storage mode depends on three questions: How large is your dataset? How fresh does the data need to be? And are you working in Microsoft Fabric? Here is the practical framework I use with clients when this decision comes up.

Choose Import Mode when:

• Your dataset fits within the Power BI size limit (1 GB compressed for Pro; larger for Premium or Fabric capacity)
• Hourly or daily refresh is sufficient — the business does not need data refreshed in real time
• You need full DAX support, calculated columns, and unrestricted Power Query transformations
• Report performance is a priority and your users expect sub-second visual rendering
• Additionally, you are not operating in a Microsoft Fabric environment and want to keep things simple

Choose Direct Query when:

• Your dataset is too large for Import Mode AND you are not yet on Fabric
• Data must be real-time — for example, live operations dashboards or fraud monitoring systems
• Compliance policies prevent data from being copied out of the source system
• Furthermore, your source database is already well-optimised and can handle concurrent Power BI queries efficiently

Choose Direct Lake when:

• You are operating in a Microsoft Fabric environment with Fabric capacity (F SKU) assigned
• Your data is already stored in a Fabric-native source: Fabric Lakehouse, Fabric Data Warehouse, Fabric SQL Database, or a mirrored database
• Your dataset is too large for Import Mode and you need fresher data than scheduled refresh provides
• Additionally, you are comfortable building calculated column logic at the lakehouse layer rather than in the semantic model

“After six years of Power BI work, Import Mode is still my first choice for almost every project. However, for large-scale enterprise Fabric deployments, Direct Lake is the mode the platform was built around — and when the conditions are right, it genuinely delivers on its promise of Import speed with real-time freshness.”

For a broader perspective on whether adopting Microsoft Fabric makes sense for your Power BI environment, I have written a detailed breakdown in my Power BI vs Microsoft Fabric guide. Additionally, if you are preparing for a Power BI role or certification, the 73 Power BI interview questions article covers storage mode concepts in a practical Q&A format.

Switching Between Connectivity Modes in Power BI

Switching between Import and Direct Query modes requires careful planning. The process — and its implications — differ significantly depending on which direction you are switching.

How to Switch from Import Mode to Direct Query in Power BI

Switching a dataset from Import Mode to Direct Query requires careful handling. Simply changing the connection mode in Power Query will lead to errors in most cases. Consequently, here is the correct step-by-step approach:

1. Identify the dataset: Open the Power BI Desktop file. Note the table names, existing relationships, and any calculated measures associated with the table you are switching.
2. Delete the existing query: Go to Transform Data and delete the query or table currently using Import Mode. Ensure you record any relationships or calculated columns before deleting, as these will need to be reconfigured.
3. Re-import the dataset in Direct Query mode: Select Get Data, reconnect to the same data source, and choose Direct Query as the storage mode. Use the same table name to maintain consistency with existing relationships.
4. Validate the model: Review all relationships and measures in the data model. Additionally, certain calculated columns or complex measures that worked in Import Mode will need to be recreated or adjusted for Direct Query.
5. Test all reports: Verify that all visuals and interactions work as expected. Furthermore, check query performance — Direct Query depends entirely on the speed and optimisation of your source system.
6. Optimise the source: Since Direct Query runs queries against the source on every interaction, ensure the source database is properly indexed. Use indexing and query tuning techniques to improve response times.

How to Switch from Direct Query to Import Mode in Power BI

This direction is simpler — however, it is irreversible. Once you switch all tables to Import Mode, you cannot switch back to Direct Query through the Power BI UI. Here is the process:

1. In Power BI Desktop, navigate to the bottom-right corner where the storage mode indicator is displayed (e.g., “Storage Mode: Direct Query” or “Storage Mode: Mixed”).
2. Click the storage mode indicator and select “Switch All Tables to Import Mode.” A confirmation dialog will appear clearly stating that this action is irreversible.
3. Confirm the switch. Power BI will reload all tables and load the data into its in-memory engine — which may take significant time depending on data volume.

You may choose to switch to Import Mode if you need better report performance, want access to advanced features like the Data View, or need full DAX support including calculated columns. Moreover, Import Mode allows offline access to data, which is useful for scenarios where a live source connection is not always available.

Real-World Scenarios and Best Practices

Scenario 1 — Sales Dashboard with Near-Real-Time Open Sales (Composite Model)

In a recent project, I managed a sales dataset that initially used Import Mode with 8 refreshes per day — sufficient for historical data analysis. However, as the team required near-real-time visibility into open sales orders, Direct Query became necessary for that specific table. To avoid upgrading to Power BI Premium for 48 daily refreshes, I adopted a Composite Model. Static tables — such as customer master and product catalogue — remained in Import Mode for fast performance, while the open sales fact table used Direct Query to maintain live updates. As a result, we balanced performance and data freshness without incurring additional licensing costs.

Scenario 2 — Marketing Dashboard Combining Historical and Real-Time Data

Another project involved a marketing dashboard where historical campaign performance data was stored in Import Mode for analysis and forecasting. Real-time engagement metrics, sourced from an external API, were integrated using Direct Query to provide up-to-the-minute insight. By carefully managing relationships and minimising cross-mode query complexity, the team achieved a seamless user experience. Consequently, Composite Models worked well here too — giving the business the data freshness it needed without sacrificing dashboard speed for the more static historical analysis.

Scenario 3 — Enterprise Fabric Migration: Direct Lake in Practice

A third scenario involves a client currently migrating their data platform to Microsoft Fabric. Their primary fact tables — several hundred million rows — were previously connected via Direct Query against an Azure SQL Data Warehouse, resulting in slow report interactions for end users. After migrating the data to a Fabric Lakehouse in Delta Lake format, we switched the semantic model to Direct Lake mode. As a result, report performance improved dramatically compared to the previous Direct Query setup, while data freshness remained near-real-time — reflecting lakehouse updates within minutes of pipeline completion.

However, the migration required rebuilding calculated column logic at the lakehouse SQL layer. Because calculated columns are not supported on Direct Lake tables, any column that was previously defined in the Power BI semantic model had to be moved into the lakehouse transformation layer. This added engineering work upfront — but the result is a cleaner separation between data preparation (lakehouse) and reporting (semantic model).

In 99% of my personal use cases, I still rely on Import Mode. It provides full flexibility, supports advanced data modeling, and delivers optimal performance for the projects I typically work on. Moreover, the datasets I encounter rarely exceed the Import size limit when modeled correctly with a star schema. Nevertheless, understanding all three modes positions you to design the right solution when scale or infrastructure demands it.

Frequently Asked Questions — Power BI Import Mode vs Direct Query

Conclusion

Choosing between Power BI Import Mode, Direct Query, and Direct Lake comes down to three questions: How large is your dataset? How fresh does the data need to be? And are you working in Microsoft Fabric?

For the majority of Power BI projects, Import Mode is still the right answer. It is faster, more flexible, supports the full range of DAX and modeling capabilities, and works with every data source. Direct Query is the right tool specifically when data freshness cannot be compromised and Import is not feasible due to dataset size or compliance requirements. Direct Lake, however, represents the future for large-scale Fabric environments: it removes the classic Import vs Direct Query trade-off, but only within the Fabric ecosystem and with meaningful constraints around calculated columns, data source compatibility, and capacity licensing.

If you are unsure, start with Import Mode. However, if you are scaling to Fabric and working with large datasets, start evaluating Direct Lake now — it is where Microsoft is investing, and understanding it positions you ahead of most Power BI developers. For a deeper look at the Fabric ecosystem, read my Power BI vs Microsoft Fabric guide. Additionally, if you are focused on Power BI dashboard design best practices, the storage mode you choose will directly influence what visual and performance optimisations are available to you.