Direct Lake, Import or DirectQuery: which storage mode when

Import, DirectQuery and Direct Lake all describe one thing: how a report reaches the data. Import makes a copy in memory, DirectQuery passes the question to the source, Direct Lake reads the Delta files in your lakehouse directly.

The choice is often made on instinct, or on whatever is newest. It pays to reduce it to three questions.

Three questions, in this order

Freshness, volume and where your data already lives, in that order.

How fresh must the answer be? If this morning's number is enough, a copy is fine. For stock or trip status that counts by the hour, querying the source becomes interesting.

How large is the table really? Not how many rows exist in the source system, but how many the model needs. Many models are large because of history nobody queries.

Is the data already in a lakehouse? Direct Lake reads Delta tables as they are. If your data sits in a classic database, that path does not exist without moving it first.

What the three modes actually do

• Import. Data is copied and compressed into the model. Fastest reports and full modelling freedom, but freshness depends on your refresh schedule and memory sets a ceiling.
• DirectQuery. Every visual sends a query to the source. Always current and no copy, but the experience is only as fast as your source and every click loads that system.
• Direct Lake. The model reads Delta files straight from storage, with no import step and no database query. Close to import speed at large volume, provided your tables are well maintained.

Not a ranking but a profile: each mode wins on one axis.

Direct Lake also has a limit worth knowing up front: when a query falls outside what can be read directly, it falls back to DirectQuery behaviour. The report still works, but the speed changes. That is not a fault, just something to know before you promise it to the board.

The choice your model is not saved by

Whichever mode you pick, it decides how fast a number appears, not whether the number is right. Three reports with three definitions of margin keep giving three answers, regardless of storage mode.

That is why the definition belongs underneath the report, in a layer that serves all three modes. It is the core of what data architecture is, and the reason we look at the catalog of a lakehouse and not only at its storage. In Databricks that layer is Unity Catalog; in other platforms it has another name and does the same work.

A practical approach

Start with Import while it fits. Move to Direct Lake when volume makes the import step unworkable and your data already sits in Delta format. Use DirectQuery deliberately, for the few tables where the last minutes genuinely count, not as the default for your whole model.

And measure before you migrate. A model that is slow because of too many columns, missing relationships or row-level calculations does not get faster from a different storage mode.