Power BI DirectQuery vs Direct Lake: two ways to skip import
DirectQuery vs Direct Lake in Power BI compares two storage modes that both avoid a full imported copy of the data. DirectQuery sends a query to the source system each time a visual needs numbers. Direct Lake loads data from Delta tables in OneLake straight into memory. So the names sound alike, but the engines behave very differently. The right mode depends on where the data lives.
- Where queries run
- Fabric capacity needed
- Say less, test more
Last updated
Power BI DirectQuery vs Direct Lake: how does each mode work?
In DirectQuery mode, the semantic model stores no data. When a reader opens a page, Power BI translates each visual into queries and sends them to the source. Therefore the source database does the work, and its speed sets the report's speed.
Direct Lake takes another path. The data sits as Delta tables in OneLake. When a query arrives, the engine loads the needed columns into memory and answers from there. Microsoft states that the same VertiPaq engine as Import mode processes those queries.
In short, DirectQuery depends on a live database for every click. Direct Lake depends on files in the lake and on memory in a Fabric capacity.
How do Power BI DirectQuery and Direct Lake compare by area?
These rows follow Microsoft's Direct Lake overview and its DirectQuery guidance.
| Area | DirectQuery | Direct Lake |
|---|---|---|
| Where data lives | In the source database | Delta tables in OneLake |
| Query engine | The source system | VertiPaq, in memory |
| License | Any Fabric or Power BI license | Fabric capacity only |
| Data freshness | Live at query time | Follows the Delta tables after framing |
| Refresh | No data refresh | A quick metadata refresh |
| Typical sources | Many relational databases | Fabric lakehouse or warehouse |
| Main limit | Source speed and query limits | Capacity guardrails |
When is DirectQuery the right mode?
DirectQuery fits when data must stay in its source. For example, some rules forbid a copy outside the database. Other tables change so often that any copy would be stale. In those cases, a live query is the honest answer.
It also fits sources that Fabric does not hold. Microsoft documents DirectQuery support for many relational databases. So a team can report on an existing warehouse without moving anything first.
However, the costs are real. Every visual sends queries, so a slow source means a slow page. Some modeling features also carry limits in this mode. Therefore we test with real data before we commit, and we often add aggregations or a composite model.
When does Direct Lake make more sense?
Direct Lake fits a team that already lands its data in OneLake. Microsoft describes the primary use case as IT-driven projects with lake-centric designs and large volumes. Because the engine reads the Delta tables, no long import refresh stands between the lake and the report.
Its refresh is different too. Microsoft calls the operation framing. It copies only metadata and points the model at the latest files, which can take a few seconds. So new data reaches readers soon after the tables update.
Still, conditions apply. Direct Lake requires a Fabric capacity, and guardrails depend on the capacity size. In some cases a Direct Lake model on a SQL endpoint falls back to DirectQuery, for example when the source is a SQL view. For a closer look at the newer mode alone, see the Power BI Direct Lake guide. To connect the lakehouse that feeds it, see Power BI Fabric lakehouse integration, and for wider platform planning, see Microsoft Fabric consulting.
Questions that settle a Power BI DirectQuery vs Direct Lake choice
Six questions narrow the decision before any build starts.
- Does the data already sit in OneLake?
- Does the company own a Fabric capacity?
- Must figures be live to the second?
- How fast does the source answer queries?
- How large are the biggest tables?
- Would plain Import mode be enough?
DirectQuery vs Direct Lake: questions from modelers
Is Direct Lake simply a faster form of DirectQuery?
No. The two work in different ways. DirectQuery passes queries to a database. Direct Lake loads column data from Delta files into memory and answers there, much as Import mode does. So Microsoft compares its query performance with Import. The shared word in the names causes most of the confusion.
Does Direct Lake need a refresh at all?
It needs a light one. Microsoft explains that a Direct Lake refresh copies only metadata and updates references to the latest files in OneLake. That differs from an Import refresh, which copies all of the data. Automatic updates can also keep the model in step with the tables.
What happens when Direct Lake cannot load the data?
It depends on the flavor. Microsoft states that Direct Lake on a SQL analytics endpoint can fall back to DirectQuery, for example for a SQL view, and a model property controls that behavior. Queries then still return results, but more slowly. We check fallback in testing so that nobody meets it by surprise.
Should we choose Import mode instead of either one?
Often, yes. Import mode remains the simplest and fastest choice for small and medium data that refreshes on a schedule. So we start there and move away only for a clear reason, such as very large tables, a need for live figures or a lake-first design.
How does Power BI Agency help with storage modes?
One of our consultants reviews your sources, volumes and capacity in a free 30-minute assessment. Then we test the candidate modes on your own tables before we recommend one. Power BI Agency is a division of Sataware Technologies and independent of Microsoft. Call (480) 485-7373 for a reply within 2 hours.
Let's build your first dashboard together.
Tell us what you report on today. A consultant replies within 2 hours with next steps.
Trusted partners
Microsoft Solutions Partner · AWS Partner
Cloud & AI Platforms
Azure SQL, Microsoft Fabric and the data pipelines behind your reports.
AI Business Solutions
Power BI reporting on your Dynamics 365, Business Central and Power Platform data.
Security
Row-level security and Entra ID sign-in on every report and workspace.
Amazon Web Services
Power BI on your AWS data, with connectors for Redshift, Athena and S3.