Import storage mode

What it does

Import mode copies source data into the model, compresses it with the VertiPaq engine and answers every query from memory. It's the default mode for a new Power BI Desktop file and it's still the fastest thing Power BI does.

Key facts

Imported data is written to disk on refresh, then loaded into memory when the model is queried or refreshed. The whole model loads — there's no concept of a partially loaded Import model.
Microsoft's rule of thumb is around ten-times compression, so roughly 10 GB of source data lands at about 1 GB in the model. On-disk storage can be about 20% smaller again than the in-memory size.
The full Power Query M function set and the full DAX function set are available, including calculated columns and calculated tables. No folding constraints, no unsupported-function surprises.
Data is only as fresh as the last refresh. A full refresh truncates every table and reloads it.
Scheduled refresh is capped at eight times a day on shared capacity and 48 times a day on Premium capacity.
A gateway is needed whenever the source isn't reachable directly over the internet.
Refresh needs processing capacity plus extra memory on top of the model's resting size, so peak memory during refresh is higher than the model size suggests.

When to use / skip

Start here and only move if you have a reason. Import gives you the best query performance, the fewest modelling restrictions and the least amount of explaining to do. Move away from it when the data genuinely won't fit or compress into the capacity you have, when the business needs data fresher than your refresh window allows, or when security has to be enforced in the source and can't be reproduced in the model. "The source is big" isn't a reason on its own — a fact table trimmed to the columns and grain the reports actually use is usually a fraction of what people assume.

Configuration decisions

The grain and the column set you import, which is where most of the size problem is solved or created.
Refresh cadence and window, and whether the source system can take that load during business hours.
Whether the model needs incremental refresh from day one or can start with a full refresh and add a policy later.
Whether the large semantic model storage format gets switched on before the first refresh, if you expect the model to pass 1 GB.
Which account owns the data source credentials and whether a gateway is in the path.

Gotchas

Refresh memory is roughly double the model footprint while the refresh runs. Capacity sizing based on resting model size will bite during the overnight window.
Auto date/time quietly creates a hidden date table for every date column in the model. On a wide model that's a meaningful chunk of your size and it's invisible until you look.
High-cardinality columns — transaction IDs, GUIDs, free-text notes, datetime stamps with seconds — kill compression. One unnecessary column can cost more than an entire dimension table.
Full refresh against a busy source at 6am is a conversation with the DBA that you want to have before go-live, not after.
Once the model is published with an incremental refresh policy you can't download the .pbix back, so keep the source file somewhere sensible.

Consultant notes

Push back on "we need real-time" early. Most of the time the business means "not yesterday's data", which a mid-morning refresh solves at a fraction of the cost and complexity.
Model size work is cheap and unglamorous but pays back more than any DAX tuning. Drop columns, round timestamps, split datetime into date and time, fix the grain.
Give the client a refresh failure runbook. Import models fail at 4am and somebody needs to know whether to rerun or escalate.
If they're already on Fabric capacity, mention that OneLake integration can write Import model tables out as Delta tables without a redesign. It's a useful bridge argument if Direct Lake is on the roadmap.

Revisit if the refresh limits per capacity type change, or once model size starts creeping towards the capacity ceiling.