Power BI live connection vs DirectQuery: who owns the model
Live connection vs DirectQuery in Power BI is a common point of confusion, because neither one imports data into the report file. A live connection attaches a report to a model that already exists elsewhere. DirectQuery keeps the model in your own file and sends queries to a database. So the real difference is where the semantic model lives and who maintains it.
- Where the model lives
- What authors can change
- One shared model
Last updated
Power BI live connection vs DirectQuery: what is the difference?
With a live connection, the report holds no model of its own. It connects to a published Power BI semantic model or to an Analysis Services model. Then every visual asks that remote model for its numbers. The author builds pages and nothing else.
With DirectQuery, the author defines the model in Power BI Desktop. Tables, relationships and measures live in the file. However, the data stays in the source, and Power BI sends queries there when a reader views a page.
In short, a live connection reuses a finished model. DirectQuery is a storage mode inside a model that you build yourself.
How do a Power BI live connection and DirectQuery compare?
The table describes the usual case for each connection type.
| Area | Live connection | DirectQuery |
|---|---|---|
| Where the model lives | In a published model elsewhere | In your own file |
| What it connects to | Power BI semantic models, Analysis Services | Relational databases and similar sources |
| Power Query | Not available in the report | Available, with limits |
| Relationships | Set in the remote model | Set by the report author |
| Measures | Shared, plus report-level measures | Written in the local model |
| Who maintains logic | The model owner | The report author |
| Best for | Many reports on one trusted model | Live data from a database |
When is a live connection the better choice?
A live connection suits a company that wants one version of each figure. A central author publishes a vetted semantic model. Then other people connect to it and build their own reports in their own workspaces. Microsoft describes this pattern as a way to manage the report lifecycle.
Because the model sits in one place, a measure changes once and every report follows. Access also stays simple. Microsoft explains that Build permission on the semantic model decides who may use it.
However, the report author gives up some freedom. There is no Power Query and no way to add a table in a plain live connection. So an author who needs extra data must ask the owner or change the connection type.
When does DirectQuery fit better?
DirectQuery fits when no shared model exists yet and the data must stay in the database. For example, a table may be too large to import, or figures may need to be current at view time. The author then builds a model over the source.
It also gives full modeling control. The author chooses the tables, sets the relationships and writes the DAX. Still, Microsoft documents limits for this mode, and the speed of each page depends on the source.
There is a middle road too. Microsoft offers DirectQuery for Power BI semantic models and Analysis Services. It turns a live connection into a local model, so an author can add tables while the core stays shared. For help designing the shared model that both rely on, see Power BI data modeling.
Questions for a Power BI live connection vs DirectQuery choice
These six questions point to the right connection type quickly.
- Does a trusted shared model already exist?
- Will several reports need the same measures?
- Does the author need to add other tables?
- Must figures be current at view time?
- Who should own the business logic?
- How fast does the source database respond?
Live connection vs DirectQuery: questions from authors
Can I add my own measures on a live connection?
Yes, in the usual case. When a report connects live to a Power BI semantic model or a tabular Analysis Services model, the author can write report-level measures. Those measures stay in that report and do not change the shared model. So a figure that many reports need should go into the model instead.
Does a live connection use DirectQuery behind the scenes?
It depends on the remote model, not on the report. The shared semantic model has its own storage mode. It may import its data, use DirectQuery or use Direct Lake. The report simply asks the model for results. So a live connection to an imported model still answers from memory.
Why is Transform data grayed out in my report?
That is normal for a live connection. The report has no local model, so there are no queries to edit. Power Query belongs to the semantic model that the report connects to. When you need to reshape data, open the file that defines that model, or ask its owner for the change.
Which option performs better?
No fixed answer exists. A live connection to a well-built imported model is usually quick, because the engine answers from memory. DirectQuery depends on the source database and on the model design. Therefore we measure real pages with Performance Analyzer in Desktop before we say one is faster.
Can Power BI Agency design a shared model for us?
Yes. One of our consultants builds the semantic model in your own tenant and shows progress in weekly demos. After that, your authors connect live and build reports on it. Power BI Agency is a division of Sataware Technologies and independent of Microsoft. Call (480) 485-7373. We reply within 2 hours.
Let's build your first dashboard together.
Tell us what you report on today. A consultant replies within 2 hours with next steps.
Trusted partners
Microsoft Solutions Partner · AWS Partner
Cloud & AI Platforms
Azure SQL, Microsoft Fabric and the data pipelines behind your reports.
AI Business Solutions
Power BI reporting on your Dynamics 365, Business Central and Power Platform data.
Security
Row-level security and Entra ID sign-in on every report and workspace.
Amazon Web Services
Power BI on your AWS data, with connectors for Redshift, Athena and S3.