DirectQuery with Power BI Dataflows (Legacy) - When to Use It and When to Walk Away

Every so often a client asks me why one of their Power BI reports takes forty seconds to load a single page. We dig in, and the answer is usually some combination of too much data, too many transformations happening at the wrong time, and a data model that grew organically until it collapsed under its own weight. Somewhere in that conversation, dataflows come up, and often DirectQuery over dataflows specifically. It is one of those features that sounds like exactly what you need until you understand what it actually does and, just as importantly, where Microsoft is steering the whole thing now.

DirectQuery with dataflows lets a Power BI report query a dataflow's data live at the storage layer rather than importing a copy into the model. Microsoft's documentation on DirectQuery with dataflows walks through the setup. What I want to give you is the consulting read: what problem it solves, why "legacy" is stamped on it, and how to decide whether to touch it at all in 2026.

First, what dataflows are actually for

Let me back up, because half the confusion here comes from people not being clear on what a dataflow is in the first place.

A Power BI dataflow is Power Query in the cloud. Instead of writing your data transformations inside a single report where only that report can use them, you build them once as a dataflow, and the cleaned, shaped result sits in storage ready for any report to consume. The point is reuse. If five reports all need the same cleaned customer table with the same business logic applied, you build that logic once in a dataflow rather than five times in five separate files that slowly drift out of sync.

This is genuinely one of the better ideas in the Power BI ecosystem, and it is underused. Most of the "why do our numbers disagree" problems we see in Australian reporting estates come down to the same transformation being reimplemented slightly differently in a dozen places. Dataflows are the antidote to that, when they are used with a bit of discipline.

Normally, a report consuming a dataflow imports the data. It pulls a copy into the model, and the report runs fast because everything is local. That is the default and, for most cases, the right choice.

Where DirectQuery over dataflows comes in

DirectQuery changes that arrangement. Instead of importing a copy, the report queries the dataflow's stored data directly at runtime. No import, no duplicated copy sitting in the model, and the report reflects whatever is currently in the dataflow storage.

The appeal is real in specific situations. If your dataset is genuinely large, large enough that importing it into the model is slow, expensive, or bumps into size limits, DirectQuery lets you avoid holding the whole thing in memory. And if you want reports to reflect the dataflow's data without waiting for a model refresh, querying it directly gets you closer to current.

So the pitch is: big data you do not want to duplicate, plus a desire to avoid the import-and-refresh cycle. On paper, that is a tidy solution.

In practice, I reach for it rarely, and I want to be honest about why.

The catch, and why "legacy" is on the label

DirectQuery is a performance trade every single time. When a report imports data, queries run against a fast in-memory copy. When a report uses DirectQuery, every interaction, every filter click, every slicer, every visual that refreshes, sends a query back to the source. If that source is fast and the queries are simple, fine. If it is not, your users feel every bit of that latency, and they feel it constantly, not just once at load.

Over dataflows specifically, this means your report's responsiveness is now tied to how quickly the dataflow storage can answer queries. For a lot of workloads that is slower than people expect, and you end up trading a one-time import cost for a permanent interactivity cost that your users pay on every click. That is often a bad trade. A slightly slower refresh that nobody watches beats a slightly slower click that everybody feels.

Then there is the word Microsoft has attached to this: legacy. That label is not decorative. It is a signal about where the platform is going, and where it is going is Fabric. The modern approach to this whole problem, large data, live query, storage you do not want to duplicate, is increasingly built around Fabric, OneLake, Direct Lake mode, and Lakehouse storage rather than the older Power BI dataflow DirectQuery path. Direct Lake in particular aims to give you something close to the best of both worlds: import-like speed without the import, querying data directly from OneLake storage. That is the direction the investment is flowing.

So when you see "legacy" on a feature, read it as: this still works, it is not being ripped out tomorrow, but it is not the future and you should not be building new long-lived architecture on top of it if you have a choice. Building your 2026 data platform on a feature Microsoft has quietly labelled legacy is a decision your future self will question.

How I actually advise clients

If you have an existing setup using DirectQuery over dataflows and it is working, do not panic and do not rip it out for the sake of it. Legacy does not mean broken. It means understand that it is a dead-end path and plan your next platform move with your eyes open. Keep it running, watch performance, and factor a migration into your roadmap rather than treating it as urgent.

If you are starting fresh and you have hit a genuine "the data is too big to import comfortably" wall, the honest answer in 2026 is to look at Fabric and Direct Lake before you reach for DirectQuery over dataflows. You get the same problem solved with the modern tooling that Microsoft is actually investing in, and you are not building on ground that is already marked as legacy. This is a real architecture decision though, not a one-click swap, and getting it wrong is expensive. It is exactly the kind of thing our Microsoft Fabric consultants exist to sort out, because the difference between a data platform that scales for five years and one you rebuild in eighteen months usually comes down to choices made right here.

And if your data is not actually that big, which is the most common case, do not use DirectQuery at all. Import mode is faster, simpler, and less fragile. I have lost count of the number of reports I have seen using DirectQuery for datasets that would fit into an import model with room to spare, purely because someone read that DirectQuery was more "real-time" and assumed newer meant better. It usually just made the report slower for no benefit anyone could point to. Reach for DirectQuery when the data genuinely forces you to, not because it sounds more advanced.

The bit people get wrong

The recurring mistake is treating DirectQuery as a freshness feature. People want their reports to show current data, they see that DirectQuery queries live, and they conclude DirectQuery is how you get real-time reporting. Then they wire it up and their reports become sluggish, and they cannot work out why the "better" option feels worse.

The truth is that most reporting does not need genuine real-time data. It needs reasonably current data, and a well-scheduled import refresh delivers that perfectly well without the constant query cost. If you actually need live operational data, DirectQuery over dataflows is rarely the right tool for that either. You would be looking at a proper DirectQuery source or a streaming setup, not a dataflow. Dataflows are a data preparation and reuse layer, and asking them to be your real-time query engine is asking them to be something they were never built to be.

Get clear on what problem you are actually solving. If it is reuse and consistent transformations, dataflows are excellent and you should import from them. If it is genuinely enormous data you cannot duplicate, look at Fabric and Direct Lake. If it is real-time operational reporting, that is a different architecture again. DirectQuery over dataflows sits in a narrow band between those, and the band keeps getting narrower as Fabric matures.

Where this fits in the bigger picture

Features get labelled legacy for a reason, and the reason is almost always that a better approach has arrived. DirectQuery over dataflows was a sensible answer to a real problem in its day. The problem has not gone away, but the answer has moved. For any organisation building a data platform they expect to rely on for years, the smart move is to understand where the platform is heading and build toward that, rather than anchoring to a path that Microsoft has already told you is winding down.

If you are wrestling with slow reports, data models that have outgrown their setup, or a Power BI estate that needs to move onto a footing that will still be right in three years, that planning work is what we do. Have a look at our Power BI consultants or get in touch and we will take a proper look at what you have got and where it should go next.