For most of Power BI's life you had two ways to connect a report to data, and you chose your poison. Import loaded a compressed copy of the data into memory: blisteringly fast to query, but a copy — so it went stale between refreshes, and a big model meant a big, slow, memory-hungry refresh. DirectQuery left the data where it lived and queried it live: always fresh, no refresh, but every visual click became a round-trip to the source, and performance was at the mercy of whatever was underneath. Two decades of Power BI architecture came down to trading freshness against speed. Direct Lake, Fabric's third option, is interesting precisely because it claims you no longer have to.

The pitch is genuinely clever. Direct Lake reads the Delta/Parquet files in your OneLake lakehouse directly into the engine — no import step, no copy to refresh — but loads them into memory in the same columnar form that makes import fast, paging columns in as queries need them. When it works, you get import-class query speed against lakehouse data that's current as of the last write, with no refresh job to schedule or babysit. For the right model that's not a marginal improvement; it retires a whole category of refresh-window pain. But "when it works" is carrying real weight in that sentence, and the honest version of this post is about the edges.

Where Direct Lake genuinely wins

  • Large models that hurt to refresh. If your import model has become a multi-hour refresh that eats memory and races the morning deadline, Direct Lake can make the refresh window simply vanish — there's nothing to import. This is the flagship win, and it's a big one.
  • Freshness without DirectQuery tax. Data that needs to be current and fast — where import's staleness was unacceptable but DirectQuery was too slow — is exactly the gap Direct Lake fills.
  • A Fabric-native lakehouse you already have. If your gold layer already lives as Delta tables in OneLake, Direct Lake removes a redundant copy and the governance headache of keeping it in sync. One version of the data, queried in place.
  • Cost and memory discipline. Not importing a full copy of a large model, and paging columns on demand, can ease the memory pressure that forces capacity upgrades. Fewer copies is cheaper in more ways than one.

Where it bites

Now the part the demo skips. Direct Lake's superpower has an escape hatch called DirectQuery fallback, and understanding it is the difference between a fast report and a mysteriously slow one.

  • Fallback to DirectQuery. When a query can't be served in Direct Lake mode — you exceed the capacity's guardrails on rows or memory, or you use something Direct Lake doesn't support — the engine silently falls back to DirectQuery against the source. The report still works, but it's now paying the DirectQuery performance tax, and your users just feel "it got slow" with no obvious cause. The fast path is conditional, and the conditions are real.
  • Cold-cache first hits. Columns page into memory on first use, so the very first query after data changes (or after eviction) can be slower while the engine warms up. Steady-state is fast; the first click may not be.
  • It wants a clean Delta table. Direct Lake is happiest against well-maintained Delta — sensibly sized files, not a million tiny ones, OPTIMIZE run, V-Order in play. Point it at a neglected, over-partitioned mess and performance suffers. The lakehouse hygiene you were putting off is now load-bearing.
  • Modelling limits. Certain constructs push you toward fallback or aren't supported the way import allows. Complex calculated columns and some patterns are better resolved upstream in the lakehouse than bolted onto the model — which is good discipline anyway, but it's a change of habit.
  • Capacity-gated. Direct Lake lives on Fabric capacity, and the guardrails scale with SKU. A model that flies on a large capacity may fall back constantly on a small one. The behaviour is a function of what you're paying for.

A pragmatic way to adopt it

  1. Fix the lakehouse first. Well-formed Delta tables, OPTIMIZEd, sensibly partitioned. Direct Lake amplifies both good and bad table hygiene.
  2. Watch for fallback explicitly. Don't assume you're in Direct Lake mode — check. Performance Analyzer and the engine's diagnostics will tell you when a query fell back. The silent fallback is the whole trap; make it visible.
  3. Model lean. Push heavy transformation and complex columns upstream into the lakehouse gold layer, and keep the semantic model thin. This keeps you on the fast path and is better architecture regardless.
  4. Size the capacity to the model. If you're seeing constant fallback, that's often a capacity signal, not a Direct Lake failing. Match the SKU to the model's real memory footprint.

The honest verdict

Direct Lake is the most genuinely useful thing to happen to Power BI connectivity in years, and for large, freshness-sensitive models on a healthy Fabric lakehouse it can retire problems that used to define the architecture. But it is not the "no more trade-offs" free lunch the headline implies. You've traded the visible, schedulable pain of refresh windows for the invisible, conditional pain of DirectQuery fallback — and invisible pain is harder to manage precisely because nobody sees it until a user complains. The tool rewards teams who keep their lakehouse clean, model with discipline, and actually watch what mode their queries are running in. Do that and Direct Lake mostly delivers on its promise. Ignore it and you'll get a fast report that's fast until, one Tuesday, for reasons nobody can name, it isn't.

Which is the recurring lesson of this whole platform, really: the clever features work beautifully on the foundations you were tempted to skip. Direct Lake didn't remove the need for a well-kept lakehouse — it just made that lakehouse the thing your dashboards' speed depends on.