September 13, 2026

Direct Lake vs Import mode: how to choose

Direct Lake reads Delta tables from OneLake with no refresh and near-Import speed — but only if the source tables are actually tuned for it.

Direct Lake gets pitched as "Import mode speed with no refresh," which is true often enough to be dangerous — it's true when the underlying Delta tables are shaped for it, and false in ways that look like a Direct Lake problem but are actually an un-tuned table. The real decision has three inputs: refresh tolerance, table maintenance you're willing to run, and query pattern.

What Direct Lake actually does

A Direct Lake semantic model reads Parquet files straight from OneLake into memory on query — no import step, no scheduled refresh, no duplicate copy of the data living inside the model. When the underlying Delta table changes, the model reframes: it picks up the new version on the next query rather than on a refresh schedule. There's no ETL into the semantic model at all; the lakehouse table is the model's source of truth.

Why it can be exactly as fast as Import — or noticeably slower

Import mode's speed comes from VertiPaq, the in-memory columnar engine. Direct Lake uses the same engine — it just fills it directly from Parquet row groups instead of from a refresh pipeline. That means Direct Lake's ceiling is Import-mode speed, but only when the files are shaped the way VertiPaq wants:

• V-Order matters more here than anywhere else. V-Order sorts and encodes Parquet specifically for VertiPaq transcoding — Fabric's own numbers put the read-side win at 15–50% on Direct Lake and SQL-endpoint scans. A table written without V-Order forces a heavier transcode on every reframe.
• File size and row-group alignment matter. Delta table optimization targets 128–256 MB files; for Direct Lake specifically, keeping a 128 MB file size aligned with the default 1M-row group size keeps transcoding cheap. Small-file tables (frequent MERGE, streaming writes) transcode expensively on every reframe until compacted.
• A cleared VACUUM window mid-query causes a silent fallback. If VACUUM removes the version a query was mid-reframe against, Direct Lake falls back to DirectQuery until the next reframe — see VACUUM & retention. That's a latency spike your users will notice and report as "the report is slow," not "the table needed VACUUM scheduling."

Skip the table maintenance and Direct Lake will still work — it just quietly degrades toward DirectQuery-like latency instead of failing, which makes the root cause harder to spot than an Import refresh simply erroring out.

When to pick each

Want a recommendation for a specific report instead of matching rows in a table? Run it through the Direct Lake vs Import advisor — same reasoning, three questions.

The CU side of the decision

Import mode's cost shows up as a scheduled refresh job — predictable, but you pay it whether or not anyone opens the report. Direct Lake's cost shows up as reframe + transcode on read, which scales with actual usage instead of a fixed schedule. For low-traffic reports that's a real saving; for high-traffic dashboards against an un-tuned table, transcoding on every reframe can cost more than a nightly refresh would have. Run the shape you're considering through the CU cost calculator before committing either way — the answer depends more on table maintenance than on the mode itself.