Choosing the wrong storage mode in Power BI can mean stale data, sluggish dashboards, or unmanageable file sizes. This lesson breaks down exactly how Import, DirectQuery, and Live Connection work under the hood — and gives you a practical framework for choosing the right one every time.
Imagine you've just been handed a project: build a sales dashboard for your company's regional managers. The data lives in a SQL Server database that gets updated every few minutes throughout the day. You open Power BI Desktop, connect to the database, and start building your report — but then a colleague asks, "Wait, are you using Import mode or DirectQuery?" You freeze. You've seen those options before, but you've always just clicked the default and moved on.
That moment of uncertainty is exactly what this lesson addresses. The choice between Import mode, DirectQuery, and Live Connection isn't just a technical detail — it's a foundational decision that affects how fresh your data is, how fast your visuals load, how large your file grows, and what transformations you're allowed to perform. Making the wrong choice for your use case can mean slow dashboards, stale data, or datasets that balloon to unmanageable sizes. Making the right choice means your report is fast, accurate, and scalable.
By the end of this lesson, you'll understand exactly what each storage mode does under the hood, when to use each one, and how to make an informed decision for any dataset you work with. No more defaulting blindly to Import mode because it's familiar.
What you'll learn:
This lesson assumes you have Power BI Desktop installed (available free from Microsoft) and that you're comfortable with the basic idea of connecting to a data source and viewing a report. You don't need to know DAX, M code, or SQL — though having a passing familiarity with databases (tables, rows, columns) will help the analogies click faster.
Before we compare the three modes, let's build a clear mental model of the problem they're all trying to solve.
When you build a Power BI report, your visuals need data — numbers, categories, dates — to display. The central question is: where does that data live at the moment your report is rendering?
There are really only two possible answers. Either the data is stored inside the Power BI file itself, loaded into memory and ready to serve instantly, or the data stays outside in its original source system and Power BI reaches out to fetch it whenever needed.
This is the essential choice that storage modes represent. Import keeps the data inside. DirectQuery and Live Connection keep the data outside. Everything else — performance characteristics, refresh schedules, feature availability — flows from that single distinction.
Think of it like this: Import mode is like photocopying a library's reference books and keeping the copies at your desk. It's fast to look things up because everything is right there, but your copies go stale the moment the originals are updated. DirectQuery and Live Connection are like walking to the library every time you need information. You always get the freshest content, but every lookup takes time for the trip.
When you connect to a data source in Import mode, Power BI copies the data from that source into a highly compressed, in-memory storage engine called VertiPaq. VertiPaq is a columnar database built directly into Power BI, and it's extraordinarily good at compression — a table with millions of rows often compresses down to a fraction of its original size.
Once the data is imported, your report has zero dependency on the source system during rendering. Every chart, every slicer, every card visual queries the local VertiPaq engine. This is why Import mode reports feel so snappy — there's no network round-trip to a database, no waiting for a server to respond.
To bring the data up to date, you trigger a refresh — either manually in Power BI Desktop (click Home → Refresh), or on a scheduled basis in the Power BI Service (the cloud platform). During a refresh, Power BI reconnects to the source, pulls down fresh data, and rebuilds the local copy.
Suppose you're building a monthly sales performance report. Your data source is an Excel workbook that the finance team updates once a month after month-end close. The data is 200,000 rows and changes only on a predictable schedule.
Import mode is ideal here. You import the data once, build all your measures and visualizations, and schedule a monthly refresh to coincide with when the finance team updates the file. Between refreshes, every manager who opens the report sees fast, consistent results — and there's nothing wrong with data that's a month old when the business process itself operates monthly.
Speed. VertiPaq's in-memory columnar storage is extremely fast for the aggregations Power BI visuals typically need — sums, counts, averages, filtered subtotals. Reports built on imported data almost always feel more responsive than their DirectQuery equivalents.
Full DAX and Power Query support. Every DAX function, every Power Query transformation is available to you. You can create complex calculated tables, merge queries from multiple sources, and apply any transformation you can imagine. This flexibility disappears in other modes, as we'll see.
Multi-source blending. You can import data from a SQL database, blend it with an Excel file, and add rows from a SharePoint list — all in the same model. Import mode is the only mode that lets you freely combine data from completely different source systems in a single model.
Data freshness. This is the dealbreaker for many use cases. Your data is only as current as your last refresh. Power BI Service allows up to 8 refreshes per day on the free tier and 48 per day on Premium. If your business needs data that's accurate within minutes, Import mode cannot deliver that.
File size and memory. VertiPaq is efficient, but it's not magic. Import a table with 50 million rows and hundreds of columns, and your .pbix file will be large, your refresh will be slow, and opening the report will consume significant memory. There are practical ceiling limits to what Import mode can handle.
Refresh windows. Every scheduled refresh takes time — sometimes significant time for large datasets. During a refresh, data may briefly be unavailable or show inconsistent intermediate states.
Tip: If your dataset has millions of rows but only the last 12 months matter for reporting, consider filtering within Power Query to import only the relevant rows. Reducing what you import is often the best first optimization for Import mode.
In DirectQuery mode, Power BI stores essentially no data locally. Instead, it stores only the metadata: the names of tables and columns, the relationships between them, and any measures you've written. The actual data rows stay in your source system.
Every time a user interacts with the report — opens it, changes a slicer, clicks a bar in a chart — Power BI generates a SQL query (or the equivalent for non-SQL sources) and sends it to the source database in real time. The database executes the query, returns the aggregated results, and Power BI renders the visual. The process happens in the background, usually transparently to the user, but it means every interaction depends on a live database connection.
You're building an operational dashboard for a call center. Managers need to see the current queue depth, average handle time in the last 15 minutes, and agents currently logged in. The underlying data updates constantly throughout the day. Importing this data is meaningless — by the time a refresh completes, the data is already stale.
DirectQuery is the right choice here. Your visuals always reflect what's in the database right now. When a manager refreshes the report page, Power BI immediately fires queries to the source and shows the current state of operations.
Real-time or near-real-time data. Since every visual query hits the live database, there's no concept of "stale data." What you see in the report reflects what's in the source at that moment.
No data size constraints from Power BI's side. You're not importing data into VertiPaq, so it doesn't matter if your source table has 500 million rows. Power BI pushes the aggregation down to the database, and only the summarized results come back over the wire.
Single source of truth compliance. Some organizations have governance policies that prohibit copying sensitive data outside its controlled environment. DirectQuery keeps the data in place and never duplicates it into a Power BI file.
Performance depends entirely on your source. This is the critical trade-off. Every visual interaction generates a query to your database. If that database is slow, overloaded, or poorly indexed, your report will feel sluggish. A well-optimized source database with proper indexing is a prerequisite for a good DirectQuery experience.
Reduced DAX and Power Query capabilities. Many DAX functions and Power Query transformations are either unavailable or limited in DirectQuery mode. This is because Power BI needs to translate your DAX into native SQL (or the source's query language), and not all DAX constructs have clean SQL equivalents. Complex calculated tables, for example, are not supported in DirectQuery.
Query storm risk. If 50 users all have the same DirectQuery report open and they're all interacting simultaneously, that's potentially hundreds of database queries per minute. This load can affect not just your report but other processes sharing that database.
Warning: Before choosing DirectQuery, have a conversation with your database administrator. A DirectQuery report without query limits or caching in place can create unexpected load on production systems. Power BI does provide a query reduction option under Options → Query Reduction to help manage this.
Live Connection is the most commonly misunderstood of the three modes, partly because it sounds similar to DirectQuery. Here's the key distinction: DirectQuery connects directly to a raw data source (a SQL database, a Snowflake warehouse, etc.). Live Connection connects to an already-built semantic model — specifically, an Analysis Services model or a Power BI dataset (now called a semantic model in newer terminology) already published to the Power BI Service.
When you use Live Connection, you're not building a new data model in Power BI Desktop. You're connecting to one that someone else (or your organization's central team) has already built and published. Power BI Desktop becomes a reporting layer — you can create visualizations, but you cannot add new tables, create new relationships, or write most types of calculated columns. You're working within the model as it was designed.
Live Connection talks to two flavors of backend:
Your company's central BI team has built a carefully governed financial model in Azure Analysis Services. It has certified calculations for revenue, margin, and EBITDA that match exactly what goes into the board presentation. Five different departments want to build their own departmental views of the data — but they need to use the same definitions, not roll their own.
Each department's analyst opens Power BI Desktop, connects via Live Connection to the Analysis Services model, and builds their own visualizations. They get the freshness and governance of the central model, while the central team retains control over the definitions. Nobody is duplicating the data or re-inventing margin calculations in five different ways.
Governed, reusable models. Live Connection enforces the use of a centrally managed model. All reports built on top of it share the same table definitions, the same calculated measures, and the same security rules. This is enormously valuable in large organizations where consistent definitions matter.
No model management burden. As a report author, you don't need to worry about refreshes, relationships, or model maintenance. That's the central team's job. You focus entirely on visualization and storytelling.
Row-level security flows through automatically. If the Analysis Services model or Power BI dataset has row-level security configured — meaning different users see different subsets of data — that security applies automatically to any report built on it via Live Connection. You don't need to re-implement it.
No model customization. You cannot add new tables, create new relationships, or write calculated columns in many scenarios. You're constrained to the model as published. If you need data that's not in the central model, you'll need to request it from whoever owns that model.
Dependency on the source model. If the Analysis Services server goes offline or the Power BI dataset is refreshed, your report is temporarily unavailable. You have no local copy to fall back on.
Modern Power BI supports something called Composite Models, which lets you mix Import and DirectQuery in the same report. For example, you might import a slowly changing product catalog (Import) and connect DirectQuery to a live transaction table, combining them with a relationship.
Composite models are a more advanced topic, but knowing they exist is important because they address the "what if I need both freshness and speed" problem. You're not forced to choose a single mode for your entire report.
Tip: If you find yourself wanting Import mode for some tables and DirectQuery for others, search for "Composite Models in Power BI" as your next learning step after this lesson.
Here's a practical way to think through the choice whenever you start a new project:
Start with a question about data freshness. Ask yourself: "How old can my data be before it becomes misleading or useless?" If the answer is "a few hours is fine," Import mode is likely appropriate. If the answer is "it needs to reflect what happened five minutes ago," DirectQuery or Live Connection is necessary.
Then ask about data volume. If your dataset has more than 10-20 million rows and you can't filter it down meaningfully, Import mode may become impractical. DirectQuery becomes more attractive as volume grows — but only if your source database can handle the query load efficiently.
Then ask about governance. Does a central, authoritative model already exist for this data in Analysis Services or the Power BI Service? If yes, Live Connection is almost always the right answer. Don't rebuild what already exists and risk inconsistent definitions.
Finally, ask about flexibility. If you need complex DAX calculations, multi-source blending, or custom Power Query transformations, Import mode is the only mode that supports all of these without restriction.
A simplified version of this thinking:
This exercise uses only sample data available inside Power BI Desktop — no external database needed.
Objective: Observe the Import mode workflow end-to-end and understand what "imported data" actually means in practice.
Open Power BI Desktop. On the Home ribbon, click Get Data, then select Web from the list of connectors.
In the URL field, enter the following address for a publicly available CSV dataset:
https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv
Click OK. Power BI will fetch the file and open the Navigator window.
You'll see a table preview. Click Transform Data to open the Power Query Editor. Notice that you're editing a query — this transformation happens before data enters VertiPaq.
In Power Query, look at the column named "Fare." Click the column header to select it, then on the Home ribbon, click Remove Columns. You've just transformed the data before import.
Click Close & Apply on the Home ribbon. Watch the loading indicator — this is Power BI actually importing the data rows into VertiPaq. When it finishes, your data is now stored locally inside the .pbix file.
In the Fields pane on the right, expand the table. Right-click on it and choose Refresh Data. This simulates what happens during a scheduled refresh — Power BI reconnects to the web source and re-imports the data.
Now navigate to the Model view by clicking the diagram icon in the left-hand sidebar. You'll see your single table represented as a box. Notice there are no connection-to-source indicators here — the model only shows what's in VertiPaq, not the source.
Reflect on these questions after the exercise:
Mistake: Using DirectQuery on an unoptimized database. This is the most common DirectQuery failure mode. The report feels unbearably slow, users complain, and the developer switches back to Import — but the real problem was always the missing indexes on the source tables. Before going DirectQuery, work with your DBA to confirm the tables have appropriate indexes on the columns Power BI will filter and group by.
Mistake: Expecting Live Connection to let you add your own data. New users often connect to a Power BI dataset via Live Connection and then try to add a new table from another source, only to find they can't. If you need to extend a Live Connection model with additional data, look into Composite Models with DirectQuery to Power BI Datasets — a specific feature designed for exactly this purpose.
Mistake: Confusing DirectQuery with Live Connection. Remember: DirectQuery goes to a raw data source (SQL Server, BigQuery, Snowflake). Live Connection goes to a semantic model (Analysis Services or a Power BI dataset). They both query live, but they connect to fundamentally different things.
Mistake: Ignoring Import mode's size growth over time. You import 2 million rows today. The table grows by 100,000 rows per month. In a year, you have 3.2 million rows. Refreshes get slower, the file gets bigger. Plan for this growth. Use incremental refresh (available in Power BI Premium and Premium Per User) to handle large, growing datasets gracefully.
Troubleshooting slow DirectQuery reports: Open the Performance Analyzer pane (View → Performance Analyzer → Start Recording, then interact with a visual). Expand any visual result and click "Copy Query." Paste that SQL into your database's query tool and run it with execution plan analysis. The bottleneck is almost always a missing index or a table scan on a large table.
Let's bring everything together. Storage mode is the foundational decision in any Power BI data model because it determines the relationship between your report and its data source.
Import mode copies data into Power BI's VertiPaq engine. It's fast, flexible, and supports every feature Power BI offers — but your data is only as fresh as your last refresh, and very large datasets can become unwieldy.
DirectQuery mode keeps data in the source and sends live queries on every interaction. It delivers real-time data and handles massive datasets, but it depends entirely on the performance of the source database and restricts some Power BI features.
Live Connection connects to an existing semantic model — either Analysis Services or a published Power BI dataset. It enforces governance and avoids model duplication, but it limits your ability to customize the underlying model.
None of these is universally "the best." The right choice depends on your freshness requirements, data volume, governance environment, and the complexity of transformations you need to perform.
Where to go from here:
Understanding storage modes is one of those foundational concepts that makes everything else in Power BI clearer — the performance characteristics, the governance strategies, the refresh architecture. You now have the mental model to make intentional, informed choices rather than accepting defaults.