Import vs DirectQuery vs Direct Lake

What it does

Three storage modes for getting data into a semantic model. Import copies data into the VertiPaq engine and queries it in memory. DirectQuery leaves the data where it is and sends a query to the source for every visual. Direct Lake reads Delta tables in OneLake with the VertiPaq engine and refreshes by re-pointing at the current files rather than copying anything.

Key facts

Import is the default in Power BI Desktop and the fastest at query time. Data compresses roughly ten-fold on load, so ten gigabytes of source data lands around a gigabyte in memory.
An Import model loads entirely into memory to be queried or refreshed. There's no partial load — the whole model is in, or it isn't queryable.
Import data is only as current as the last refresh, and a full refresh truncates and reloads every table. Incremental refresh exists precisely to avoid that.
DirectQuery removes the refresh problem and the memory ceiling, and pays for both with query latency and dependence on the source database's performance.
Composite models let you mix the modes in one model, which is how aggregations work — a small Import aggregate table over a large DirectQuery detail table.
Direct Lake needs a Fabric capacity licence. Import and DirectQuery run on any Power BI or Fabric licence including free.
Direct Lake refresh is framing — a metadata operation that takes seconds because no data moves.
Direct Lake comes in two flavours with materially different behaviour: Direct Lake on OneLake never falls back to DirectQuery; Direct Lake on SQL falls back when it can't read the Delta table directly, which succeeds with a warning rather than failing loudly.
Direct Lake carries per-SKU guardrails on parquet files, row groups, rows per table and model size. Breaching them either fails the model or triggers fallback, depending on flavour.

When to use / skip

Start with Import and make someone argue you out of it. It is faster, more flexible, supports the entire DAX and M surface, and it's what most Power BI features were designed around. The overwhelming majority of business models — a few hundred million rows or fewer, refreshed nightly — should be Import, and the client who insists on DirectQuery "because the data must be live" almost never has a requirement that survives the question "live to what tolerance, and who makes a different decision in the four hours between refreshes?".

DirectQuery earns its place in three situations: the data genuinely won't fit or won't compress, there's a real sub-minute latency requirement someone will act on, or a compliance rule forbids copying the data. Not "the source is already fast" — a well-indexed warehouse still can't compete with VertiPaq for aggregate queries, and the report will feel slower than the client expects.

Direct Lake is a data platform decision dressed as a Power BI feature. If the gold layer already lives in OneLake and the client is investing in Fabric, it's the right answer and the refresh story alone justifies it. If the transformation work happens somewhere else, or the modeller can't write to the lakehouse, you'd spend the project rebuilding modelling logic upstream to compensate for what Direct Lake doesn't support.

Configuration decisions

Data volume after compression, not before. Ten-to-one is the working rule; measure it on a sample rather than estimating.
The actual latency requirement, expressed as a number and tied to a decision somebody makes. "Real time" without that is a preference, not a requirement.
Whether the client has a Fabric capacity and a lakehouse anyone maintains. Both must be true for Direct Lake to be on the table.
Whether a composite model with aggregations solves the problem instead — small Import aggregate, DirectQuery detail, and most queries never reach the source.
Where transformation logic lives, given each mode restricts what you can do in the model itself.
On Direct Lake, which flavour, since that fixes composite model options, fallback behaviour and how security is enforced.

Gotchas

DirectQuery report performance is a function of the source database, not of Power BI. Every visual is a query, and a page with twelve visuals is twelve concurrent queries per interaction. Clients blame Power BI.
Silent fallback on Direct Lake on SQL is the one that ruins a delivery. A non-materialised SQL view falls back to DirectQuery every time, and the client is running DirectQuery performance while believing they're on Direct Lake.
Import models must fit in memory alongside refresh overhead. Sizing to the published model-size limit is how you get intermittent refresh failures.
Direct Lake performance is largely a function of how tidy the Delta tables are. Lots of small parquet files after a chatty write process will breach guardrails long before the row counts look alarming.
"No refresh" on Direct Lake doesn't mean no data engineering. The cost moves upstream to whoever maintains the Delta tables, and that person may not know yet.
Direct Lake on OneLake doesn't apply row-level security enforced at the SQL analytics endpoint. Switching flavour can quietly change who sees what.

Consultant notes

Ask the latency question in the first workshop and write the answer down. It's the question that settles most of the architecture, and it's usually never asked.
Build a proof of concept for Direct Lake. Microsoft recommends it in the docs, which is unusually direct for them, and it's the quickest way to discover whether the Delta tables are in good enough shape.
When a client insists on DirectQuery, agree to it and add source-side tuning to the plan — indexes, materialised views, a proper star schema in the warehouse. Otherwise the performance complaint arrives with your name on it.
Frame Direct Lake as a platform bet. If the client isn't investing in the lakehouse, the argument doesn't hold and you're better off with Import.
Composite models with aggregations are the answer nobody proposes and the one that most often fits. Keep it in the pocket for the "too big for Import, too slow in DirectQuery" conversation.

Direct Lake's limitations list changes often — recheck before you promise any restriction here to a client