This is a blog post I’ve been meaning to write for a long time. Since Fabric launched there has been a lot of focus on Direct Lake mode in Power BI and a lot of people used it because it was the cool new thing. Arguably, we at Microsoft have been guilty of telling people to use it because it was the cool new thing without properly explaining what the benefits are of using it. Direct Lake doesn’t completely replace other storage modes: in a recent post I talked about when Import/DirectQuery composite models are the best choice; Marco wrote a good article on Direct Lake vs Import mode which makes the case for the continuing relevance of Import mode for many scenarios. So what are the main benefits of using Direct Lake mode? Here are the ones I think are important:
Faster and cheaper “refresh”
Refreshing an Import mode semantic model can be slow and can consume a lot of CUs on your capacity. Refreshing a Direct Lake semantic model (also known as framing) is almost instant and consumes minimal CUs. So Direct Lake is better, right? Well no, it’s more complicated than that. Even if refresh is cheap in Direct Lake mode you still need to get the data into OneLake in order to use it, and even if you have data in an existing lakehouse you may need to create a copy to apply additional transformations or to apply VOrder or other table-level optimisations, and it’s the cost and performance of this creation of a gold layer of tables that you should compare with Import mode refresh.
The good news is that it is often faster and cheaper to use another Fabric engine, like Spark, to load the data you need into your gold layer in OneLake than to do an Import mode refresh. For example, in this post on reddit my colleague David Browne gives a simple example of how loading a 20 million row fact table in Spark is half the cost in terms of CUs and marginally faster than refreshing the same table in Import mode; this other post on reddit has similar findings. Other BI projects I’ve seen have shown significant improvements in the time and cost of the operations needed before your end users can view reports with the latest data. Of course there are a lot of factors involved here (How frequently do you need to refresh? Are you using incremental refresh? Are you partitioning your fact table and increasing the amount of parallelism during a refresh? etc) and it is true that, at least at the time of writing, Direct Lake may be marginally slower to query than Import and will have different CU cost characteristics when queried. But the evidence is strong enough for me to say that you should do some testing to see whether Direct Lake will be faster and cheaper for your project.
There are other aspects of cost that need to be taken into account. For example, this “shifting left” of development effort from semantic model refresh to loading data into OneLake means that a specialised set of Power BI semantic model skills around Import mode refresh can be replaced by more commodity skills in areas such as Spark. You may also be able to eliminate a layer in your architecture by using Direct Lake: I’ve seen cases where a relational database is put on top of a data lake just to serve data for Import mode refreshes, something that isn’t necessary with Direct Lake.
My friends who work on internal Microsoft BI teams (who are, incidentally, some of the most sophisticated Fabric developers that I know) tell me that they prefer Direct Lake over Import because it makes them a lot more productive, again reducing costs. One reason is because it means that if they discover a bug in their semantic model that means they have to refresh, they can have their semantic model ready to be queried in seconds once the bug is fixed. They can also do things like run unit tests on feature branches before merging into their repo by spinning up a test semantic model in seconds, querying it then tearing it down again.
Avoidance of memory limits and timeouts during refresh
When you’re working with large Import mode semantic models it’s fairly common to run into errors when you hit memory limits or timeouts during refresh. This can be frustrating. These limits don’t exist when you’re loading data into OneLake for consumption by a Direct Lake model, and while there are plenty of other things that can go wrong when loading data depending on the Fabric workload you’re using, in general Import mode refreshes are harder to manage and require more specialised knowledge.
Reuse of data by multiple semantic models
Think how many Import mode semantic models there are in your tenant. Think how many copies of the same dimension tables, like the Date or Product or Customer dimension tables, there are across them. There may even be cases where the same fact table is duplicated across multiple semantic models. All of these duplicate Import mode tables need to be refreshed individually, which takes time and costs CUs, and refreshing them at different times may result in different semantic models containing different data.
On the other hand, if you plan ahead and use shortcuts judiciously, you can load all of your fact and dimension tables into OneLake once and use them in as many Direct Lake semantic models as you want. This can greatly reduce the CU cost and the time it takes before your data is ready to be queried by a report; it also means that all the semantic models contain exactly the same data. I haven’t seen many cases where people have taken advantage of this yet – probably because it does require you to plan ahead – but where it does happen it leads to huge efficiency gains. And with OneLake security you can apply security once and have it enforced consistently across all Direct Lake semantic models that use the same tables.
In the future it seems likely we’ll be moving away from large, complex semantic models that contain all the data an end user might possibly need to smaller, more focused models that work better for AI. At the same time, while a traditional Power BI report can only connect to one semantic model, the new Rayfin/Fabric apps can connect to multiple semantic models. This means it’s even more likely that the same tables will need to be present in several different semantic models.
Reuse of data by different Fabric engines
Finally, building on that last point, when all of your data is in OneLake with OneLake security applied, it’s not only available to be consumed via Direct Lake semantic models but also by any of the other Fabric engines: it can be queried in SQL via the SQL Endpoint, analysed using code in notebooks and so on. While it is possible to write the contents of an Import mode model to OneLake using the OneLake integration feature, it makes a lot more sense just to load the data into OneLake and use Direct Lake instead if you care about this.
Summary
Maybe the one thing I would disagree with Marco on in the article I referenced above is his statement that Direct Lake is only useful for the 2-3% of semantic models that are hard to manage in Import mode – those that are above 200-400GB in size. While I don’t think you should rip and replace any existing Import mode models that are currently working well, and while very large models will need DirectQuery fact tables, I think the reasons I’ve listed above mean that any new enterprise-scale project that is built completely on Fabric should at least consider using Direct Lake. I’m sure there are people out there who feel differently though, so let’s have a discussion in the comments!
[Thanks to David Browne, Justin Martin, Tamas Polner and Christian Wade for their help writing this post]
Hi Chris, nice post that I largely agree with. One thing I’d call out though is that I wouldn’t downplay the difference in query performance. Most of the focus here seems to be on the refresh times, and that’s important. However, I’m a fan of optimizing for the most common use case. and our models spend most of their time being read, not updated. But yes, the ability to do small updates quickly is amazing, compared to refreshing a whole model.
There are two concerns I have with how I see DirectLake being used.
One is the trend to just get a copy of transactional data straight in, and start using it for DirectLake. (Fabric mirroring I’m looking at you). So many Microsoft demonstrations seem to assume it’s ok to just build the analytics directly over a copy of the transactional data, yet generally, it isn’t.
My second concern is around point in time consistency. It’s great that you can update the data quickly and have it reported on immediately, but how does that play out with the consistency of the data. I see way too many systems where the lake is left in an inappropriate state while this is happening, and there’s no point of consistency. What on earth does that mean for their reporting and analytics?
Hi Chris,
just for completeness: in May 2025 I published an important update:
https://www.sqlbi.com/blog/marco/2025/05/13/direct-lake-vs-import-vs-direct-lakeimport-fabric-semantic-models-may-2025/
Why combining DirectLake + Import could be a win-win?
As Greg Low pointed out in another comment, somewhere you should transform data – even just for aesthetic purposes in the semantic model (shorter month name, sort order, any other kind of “maquillage” for visualization purposes – but usually there is also much more from a data consistency and validation point of view). However, let’s just focus on the aesthetic purposes – when you consider them:
– A pure Direct Lake solution could force you to create several versions of the same dimension using different transformations.
– The recent introduction of context-aware calculated column can be an option, even though it’s currently in preview and not fully integrated with the development tools (available from Microsoft). Nevertheless, it’s an option, and it could have performance implications, so it’s not necessarily the first choice even when you have it available (especially for “large” dimensions).
– Using a SQL view for dimensions and import it is so much easier, keeping fact tables in Direct Lake mode combines the best of the two worlds. In my experience, the pain point of refresh is limited to fact tables, sometimes just a few of them.
I definitely agree that customers should test different options, each use case may vary. For example, I have successful use cases of models in Import mode hosted in Power BI Premium per User workspaces, where the Fabric workspace (sometimes just an F2) is only used for data transformation. Companies with less than 100-200 employees may definitely explore this option, too. Topic for a future article, I guess!
Thanks!
Marco
I agree that there is a need for somewhere where semantic model developers to customise their source – the solution that Power Query solves for Import mode and views solve on relational sources. There are some ongoing discussions about this that I’m involved in 😉
Hi Chris, thanks for writing about this.
Another wrinkle here is that development and deployment can become more complex. Let’s take the extremes for illustration purposes: an Import-mode, self-contained semantic model versus a Direct Lake model on top of a Fabric warehouse.
For the latter, you generally need an additional process or artifact—a dataflow, notebook, pipeline, SQL process, etc.—to load and transform the data in the warehouse. That’s another component to develop, deploy, and coordinate.
Regarding deployment, with a self-contained Import model, deployment can be as simple as overwriting the existing model in the production workspace. With Direct Lake, database changes may need to be coordinated with semantic model changes. For breaking schema changes in particular, the deployment sequence becomes important: the currently published semantic model and the updated warehouse schema must remain compatible throughout the process, or some period of unavailability—or a more sophisticated deployment strategy—may be necessary.
Chris, From both a conceptual and practical standpoint I LOVE DL on OL. We love the “shifting left” of the import to happen in our deltalake tables. We love the decreased memory, the ability to pull the same data into multiple models (ie. composite models on steroids), etc.
PIVOT TABLES:
However it still seems like an incomplete solution. We heavily use pivot tables at our organization and, for whatever reason, the team that introduced this DL-on-OL still won’t fix the “analyze in excel” ribbon. This has important features like the ability to manage sets and calculated measures, used for specific use-cases.
Given that framing/transcoding are comparable to a “just-in-time” import operations, it seems technically *possible* for this team to re-introduce the pivot table functionality (session-scoped assets that are introduced by users).
It might be helpful to see a blog that tells us whether they are ever going to re-introduce this behavior that we lost. We know that DL on OL is a game-changer but users don’t want to sacrifice some of the important functionality that they’ve had in Excel for decades (via import models). Back when we moved from multidimensional to tabular, we lost some good stuff and now, many years later, we keep losing stuff. Excel isn’t going away any time soon, so I don’t know why the experience is being degraded.
That’s an interesting question and one of my friends in engineering is taking a look to see if there is a good reason why it’s disabled for DL/OL. There is a good reason why it’s disabled for DQ and therefore DL/SQL.
Query -scoped sets and calculated measures work fine with DL/OL.
I really can’t conceive why session-scoped would fail to work, if the equivalent query-scoped items work fine.
(Also even if these things are properly disallowed for some unexplained reason, the experience leaves much to be desired. The Excel ribbon allows you to go thru the process of building a calc, and testing it, and getting an acknowledgement that the calc is good, only to fail at the VERY last minute when trying to add it to the session.)
Hi Chris,
One aspect I still struggle with when discussing Direct Lake as a strategic architecture is semantic layer reusability.
Direct Lake gives us a great foundation for creating a single source of truth, allowing multiple semantic models to reuse the same Delta tables in OneLake and maintain consistent data. However, this feels like only part of the overall semantic layer story.
While we can create business-friendly table and column names in the Warehouse or Lakehouse, most semantic model metadata still appears to be model-specific. Things like display folders, descriptions, synonyms, hierarchies, perspectives, and other self-service enablement features need to be recreated or deployed separately to each semantic model.
Do you see a path toward truly reusable semantic artifacts, where these semantic attributes could be centrally managed and consistently reused across multiple semantic models in the same way that Direct Lake enables data reuse?
I’d be interested to hear your thoughts on how Microsoft sees this evolving, especially for organizations trying to build a scalable semantic layer strategy.
Thanks.
This is something that we are thinking about. Wait and see!
I thought that the deprecated “metric sets” was heading that way. I think we need to be able to publish “semantic tables” in Fabric that could let us build semantic models. Really just using TMDL files.