Direct Lake is not a free upgrade

The pitch is easy to like. Direct Lake reads Parquet files straight out of OneLake, so there is no import, no scheduled refresh, and no separate copy of the data sitting in a semantic model going stale. For a small team the refresh schedule is often the single most fragile thing they own, and Direct Lake deletes it outright.

So I moved a reporting layer onto it, and then read the fallback rules properly.

What I had not accounted for

Direct Lake does not cover everything. Certain constructs push the model into DirectQuery fallback, and when that happens performance stops being a property of the storage format and starts being a property of whatever is underneath. The reporting did not break. It became unpredictable, which for the person who has to trust a number in a board meeting is worse than being consistently slow.

The alternative I had rejected

Import mode. It is unfashionable and it works. You pay for it with a refresh window, a memory ceiling, and a copy of the data you now have to reason about — but you get performance that behaves the same on Tuesday as it did on Monday.

What I would do differently

Decide on the reporting patterns first, then pick the storage mode — not the other way round. If the model needs constructs that trigger fallback, import mode is not a step backwards. It is the correct answer to the question actually being asked.

Direct Lake earns its place when the gold layer is clean, wide and boring. That is a statement about your modelling discipline, not about the feature.