Direct Lake Explained

Faster Power BI Without the Refresh Tax

Direct Lake is a Microsoft Fabric feature that lets Power BI read your data straight from storage and return answers at full speed, without the scheduled refresh that Import mode depends on. If your reports are slow to refresh, always a little stale, or prone to breaking overnight, Direct Lake removes that whole class of problem. This guide explains what Direct Lake is, how it works, where it fits, and how to get it right. 

01

The Plain English Definition

Direct Lake is a storage mode for Power BI semantic models, the third option alongside Import and DirectQuery. Instead of copying your data into Power BI on a schedule, it reads the Delta tables sitting in OneLake, Fabric’s storage layer, and loads them into memory as queries need them. You get the speed of Import mode with none of the refreshing, because there’s nothing to refresh: the report always points at the latest data in the lake. 

02

What “The Refresh Tax” Means

Import mode is fast because it copies your data into Power BI’s in-memory engine. The price is the refresh: a scheduled job that reloads that copy, duplicates your data, leaves a stale window between runs, and fails often enough to ruin a morning. For large models, that refresh becomes the single biggest operational cost and the most common thing to break. That’s the tax Direct Lake removes. 

03

The Three Storage Modes, Briefly

Import copies data in for speed but needs refreshing. DirectQuery leaves data at the source for freshness but pays a speed penalty on every query. Direct Lake is the third path: it reads from OneLake fast enough to feel like Import, while staying as current as the lake itself. It’s the mode Microsoft built Fabric around. 

04

Why It Only Exists in Fabric

Direct Lake works by reading Delta tables in OneLake, so it only exists where OneLake does: inside Microsoft Fabric. Your data has to live in a Fabric lakehouse or warehouse as optimized Delta tables for Direct Lake to read it. That prerequisite is the part teams most often underestimate. 

05

The Business Case in One Sentence

The refresh window that used to dominate Import-mode operations, the nightly reload, the stale hours, the failed jobs, largely disappears, which is why data-heavy teams treat Direct Lake as the reason to move reporting onto Fabric. 

How Direct Lake Works

Direct Lake isn't magic, and understanding the mechanics helps you use it well. A few concepts do the heavy lifting. 

It Reads Delta Tables in OneLake

Your data in OneLake is stored as Delta tables, which are Parquet files organized by column. Power BI’s in-memory engine, VertiPaqreads those columns directly. Because the format is already columnar and optimized, it loads fast, without a separate extract-and-load step. 

It Loads Columns on Demand

Direct Lake doesn’t load your whole model into memory up front. When a query arrives, it works out which columns it needs and loads just those from OneLake, a process called transcoding. Most queries touch a fraction of the columns, so the memory footprint stays small. 

It Caches What's Hot

Once a column is loaded, it stays cached for the next query. Frequently used columns stay resident; rarely used ones get evicted under memory pressure and re-read from OneLake if needed later. The engine manages this automatically, with no tuning from you. 

It Frames to the Latest Data

When the underlying Delta table changes, a new write, a streaming append, a batch load, the model frames: it points at the new version of the table. There’s no refresh step, so reports pick up new data without a scheduled reload. This is what keeps them fresh. 

When It Falls Back to DirectQuery

In one variant, Direct Lake on the SQL endpoint, a query can fall back to DirectQuery when it can’t be served from the lake directly, for example when guardrails are exceeded or security is enforced at the SQL layer. Fallback is seamless but slower, so good design aims to avoid it. The newer Direct Lake on OneLake variant doesn’t fall back at all. 

The table places the three modes side by side. 

Storage Mode How It Gets Data Trade-Off
Import
Copies data into Power BI on a schedule
Fast, but needs refreshing and duplicates data
DirectQuery
Queries the source live on every interaction
Always fresh, but slower per query
Direct Lake
Reads Delta tables in OneLake on demand
Import-like speed with no refresh

Import trades freshness for speed, DirectQuery trades speed for freshness, and Direct Lake gets close to both at once, provided your data is sitting in OneLake ready to read. 

Why Direct Lake Matters for Mid-Market Businesses

For mid-market companies in Texas and across the USA, Direct Lake changes a few things that used to be constant headaches. 

Reports Stay Fresh Without Refreshes

The refresh schedule, and the staleness and failures that came with it, largely goes away. Reports reflect the latest data in the lake, which for many teams is the difference between yesterday’s numbers and current ones. 

It Scales to Large Data on Modest Capacity

Because Direct Lake doesn’t hold the whole model in memory, it can serve reports over very large tables, into the billions of rows, without the memory bill an equivalent Import model would run up. 

It Simplifies the Architecture

There’s one copy of the data, in OneLake, that both your engineering and your reports read. That removes the duplicated import copy and the drift that comes with keeping two versions in sync. 

Faster Time to Insight

New data in the lakehouse shows up in reports without waiting for a refresh cycle, so the gap between something happening and someone seeing it on a dashboard shrinks. 

What Direct Lake Is Not

Direct Lake gets oversold as a switch you flip, so it helps to be clear about what it isn't. 

It Is Not Magic on Any Data

Direct Lake only reads Delta tables in OneLake. If your data lives in a SQL Server, a stack of spreadsheets, or an external warehouse, it has to be landed in a Fabric lakehouse first. Getting your data into that shape is a data engineering job, and it’s the prerequisite most teams underestimate. 

It Is Not DirectQuery

Direct Lake doesn’t send a SQL query to a database for every report interaction. It loads columns into memory and answers from there, which is why it’s fast. The two get confused because both leave data outside Power BI, but the performance is worlds apart. 

It Is Not Free of Sizing

Direct Lake runs on Fabric capacity, and it has guardrails, limits on table size, model size, and memory per query, tied to your SKU. Exceed them and you either fall back to DirectQuery or, in the OneLake variant, the query fails. Right-sizing capacity is part of the job. 

It Is Not Automatic for Existing Models

You can’t flip an Import model to Direct Lake and expect it to work untouched. Moving means landing the data in OneLakeoptimizing the Delta tables, and checking your DAX and security for anything that triggers fallback. It’s a migration, done one model at a time. 

It Is Not a Fix for a Bad Model

Direct Lake makes a good model fast; it doesn’t rescue a bad one. A tangled, snowflaked model with heavy calculated columns will perform poorly and trigger fallbacks. The modeling discipline that mattered before matters just as much here. 

Direct Lake on OneLake vs Direct Lake on SQL

As of 2026 there are two flavors of Direct Lake, and the difference matters for new projects. 

Aspect Direct Lake on OneLake Direct Lake on SQL Endpoint
Reads via
OneLake directly
SQL analytics endpoint
DirectQuery fallback
No, query fails if over guardrails
Yes, falls back and slows down
Security
OneLake security
SQL endpoint RLS and CLS
Composite models
Supported, mix with Import
Limited
Best for
New models, Microsoft’s pick
Models needing SQL-layer security

For most new work, Direct Lake on OneLake is Microsoft’s recommended optionit’s stricter about sizing, but it avoids the hidden slowdown that fallback introduces. 

Where Direct Lake Delivers the Most Value

Direct Lake pays off most in a few situations. It shines on large models that were painful to refresh, turning a nightly ordeal into a non-event. It suits teams that need near-current reporting without the cost of true real-time. It's a natural fit for anyone already building on Fabric, since the data is in OneLake anyway. And it's a clean way to consolidate a sprawl of import models that each kept their own duplicate copy. The common thread is data that's big, fresh, or both, sitting on a foundation worth reading directly. 

How to Get Direct Lake Right

Land Your Data in a Fabric Lakehouse

Direct Lake reads Delta tables in OneLake, so step one is getting your data there, cleanly modeled, in the right format. This is the foundation everything else rests on, and it’s where most of the real work lives. 

Optimize Your Delta Tables

Compact small files, apply V-Order, and keep table maintenance current. Well-optimized Delta tables are what let Direct Lake load fast and stay inside its guardrails. 

Size Capacity for the Working Set

Direct Lake’s memory need is driven by the columns your queries touch, not the whole model. Size your capacity for that working set, with headroom, so heavy reports don’t hit limits. 

Design to Avoid Fallback

On the SQL-endpoint variant, simplify row-level security, move calculated columns into your ETL layer, and test DAX for patterns that trigger DirectQuery. Every avoided fallback keeps a report fast. 

Keep the Model Clean

star schema, clear relationships, and lean measures matter as much under Direct Lake as anywhere. The mode rewards a disciplined model and punishes a messy one. 

Taking the Next Step With Direct Lake

Start With the Data Foundation

Most of the value, and most of the disappointment, traces back to the state of the data in OneLake. Time spent getting the lakehouse and the Delta tables right pays back on every query. 

Migrate One Model at a Time

Direct Lake isn’t an all-at-once switch. Move a model, validate its performance and freshness, tune it, then move the next. A staged migration surfaces problems while they’re small. 

Final Thoughts on Direct Lake

Direct Lake is the closest Power BI has come to fast and fresh at the same time, as long as the data underneath it lives in a clean, well-optimized lakehouse. Get the foundation right and the refresh tax simply stops being something you pay. Skip it, and Direct Lake can’t help you. 

Get an Outside Assessment

The hardest part is judging where your work truly centers and whether one platform or both serve it best. A neutral partner can keep that decision grounded in your real workloads and total cost rather than a vendor pitch. 

Put Direct Lake to Work With Allston Yale

If your Power BI refreshes are slow, stale, or fragile, Direct Lake may be the fix, but only once your data is in the right shape underneath it. We’re Texas-based Power BI and Microsoft Fabric consultants, and our Power BI consulting gets your reporting onto a clean Fabric foundation so Direct Lake delivers fast, fresh reports instead of fallbacks and surprises. Book a free data check-up with us today. 

Scroll to Top