Import mode (Power BI)

What is Import mode?

Import mode is the default storage mode for Power BI semantic models. During a refresh, Power BI copies data from the source, compresses it column by column with the VertiPaq engine, and stores it in the model. Reports then answer visual queries from that fast copy instead of asking the source database every time a user clicks a filter.

That is why Import reports usually feel quick. The data is already prepared for analytics, loaded into memory when needed, and optimised for Power BI's calculation engine.

The trade-off is freshness. An Import model shows the state of the data at the last successful refresh. If the source changed five minutes later, the report does not know until the next refresh.

How Import mode works

Power BI reads the source data, applies Power Query transformations, compresses the result, and stores it as a semantic model. When users open a report, the model is loaded into memory and VertiPaq answers the DAX queries behind visuals, filters, and slicers.

Microsoft's own guidance still uses a useful rule of thumb: because of columnar compression, 10 GB of source data can often become around 1 GB in the model. The exact ratio depends on cardinality, column types, repeated values, and how much unused data you removed before loading.

Import mode is also flexible. It supports the full Power Query experience, calculated columns, calculated tables, measures, and the usual Power BI modelling patterns. That is why it remains the starting point for most classic BI reports.

When to choose Import mode

• Classic management reporting. Sales, finance, HR, operations, and service dashboards that refresh daily or several times per day.

• Fast user interaction. Users expect slicers, visuals, and drill-downs to react quickly.

• Mixed sources. One model can combine SQL, files, APIs, dataflows, and spreadsheets.

• Protecting operational systems. Report traffic hits the imported copy, not the live ERP or CRM database.

• No Fabric capacity yet. Import works in ordinary Power BI scenarios, while Direct Lake needs a Fabric capacity.

Rule of thumb: start with Import unless you have a specific reason not to. Most reporting problems are better solved by good modelling, incremental refresh, and a sensible refresh schedule than by switching to a live mode too early.

Import versus DirectQuery versus Direct Lake

Freshness
Import shows the latest refreshed copy. DirectQuery queries the source when the user interacts. Direct Lake reads Delta tables in OneLake and updates by reframing metadata rather than copying the whole model.

Performance
Import is usually the fastest for interactive reports because VertiPaq answers from a compressed in-memory model. Direct Lake can come close in a Fabric lakehouse or warehouse setup. DirectQuery depends on the source system and the generated queries.

Data volume
Import is bounded by model size, memory, and refresh time. DirectQuery leaves the data at the source. Direct Lake is designed for large Delta tables in OneLake and pages in what queries need.

Source load
Import loads the source during refresh. DirectQuery loads the source on every user interaction. Direct Lake reads analytical files in OneLake rather than the operational source.

Functionality
Import gives the broadest modelling freedom. DirectQuery and Direct Lake have limitations that you should check before committing to them.

Refresh limits and model size

Refresh limits change over time, so check Microsoft Learn before designing a critical process around them. As of the current Microsoft documentation, shared capacity allows up to eight scheduled semantic model refreshes per day. Premium, Premium Per User, and Fabric capacity allow up to 48 scheduled refreshes per day in the semantic model settings. XMLA-based refreshes can go beyond those fixed schedule counts, but capacity resources and concurrency still decide what is practical.

Refresh duration matters too. Data refreshes on shared capacity must complete in less than two hours. On Premium capacity, Microsoft documents a five-hour maximum, while XMLA refresh can bypass that limit in some scenarios.

The default semantic model size limit is 1 GB in Pro-style workspaces. With supported Fabric, Premium, Embedded, or PPU setups, the Large semantic model storage format lets models grow beyond the default, subject to capacity limits and admin settings.

Keeping large Import models healthy

Remove unused columns early
Text columns with many distinct values are expensive. If no report uses them, do not load them.

Use a star schema
Separate fact and dimension tables compress and query better than one wide export table.

Use incremental refresh
For large fact tables, refresh only the recent partitions that can still change. Historical partitions stay in place.

Watch refresh history
A failed overnight refresh means users are looking at stale data. Turn on notifications and review failures before the morning meeting.

Do not refresh constantly to simulate live data
If the business truly needs live numbers, consider DirectQuery or Direct Lake. Import is for fast reporting on a managed copy.