What Every Developer Needs to Know
If you’ve been building Power BI reports for a while, you know the drill: refresh fails at 2 AM, capacity alerts blow up your inbox, and your manager asks why the dashboard is showing yesterday’s numbers.
The answer might not be your DAX. It might be your storage mode.
Let’s break down the two most talked‑about options in Microsoft Fabric, Import Mode and DirectLake, and walk through exactly how to migrate from one to the other.
What Is Import Mode?
Import Mode has been the default in Power BI for years. When you use it, your source data gets physically copied into the in-memory xVelocity engine inside your semantic model.
How it works:
- You set up a refresh schedule (hourly, daily, etc.)
- Power BI pulls data from the source and loads it into memory
- Reports query that in-memory copy — which is why they’re fast
The trade-off:
As your data grows, so does the memory footprint. Refresh windows get longer, Premium capacities start throttling, and your data is always slightly stale between refreshes.
Import Mode works great when:
- Your dataset is small to medium in size
- You need very fast DAX performance with complex measures
- Your data source isn’t in OneLake / Microsoft Fabric
- You need an offline or disconnected report scenario
What Is DirectLake?
DirectLake is Microsoft’s answer to the scale problem and it changes how Power BI reads data.
Instead of copying data into memory, DirectLake reads Delta/Parquet files directly from OneLake, Fabric’s unified storage layer. There’s no import step, no scheduled refresh, and the data stays current.
How it works:
- Your data lives in OneLake as Delta tables (via a Lakehouse or Warehouse)
- Power BI loads column segments into memory on demand (called framing)
- If a query can’t be served from memory, it falls back to DirectQuery
DirectLake works great when:
- Your data lives in a Fabric Lakehouse or Warehouse
- You’re working with large or rapidly growing datasets
- You need near real-time data freshness
- You want to reduce data movement and storage cost
Import Mode vs DirectLake a Comparison
| Import Mode | DirectLake | |
|---|---|---|
| Data location | Copied into model memory | Stays in OneLake (Delta files) |
| Refresh needed | Yes — scheduled/on-demand | No import refresh required |
| Data freshness | Stale between refreshes | Near real-time |
| Dataset size | Tied to capacity memory | No practical limit |
| DAX performance | Fastest (xVelocity engine) | Very fast (with framing) |
| Fallback mode | None | DirectQuery fallback |
| Requires Fabric | No | Yes (F64+ SKU recommended) |
| Best for | Small/medium, complex DAX | Large, Fabric-native datasets |
A 10-Step Checklist
Thinking of making the switch? Here’s what to do:
Step 1 — Verify your Fabric capacity
Confirm you’re on an F64 SKU or higher with OneLake enabled. DirectLake requires Fabric capacity.
Step 2 — Move your data to OneLake
Use Dataflow Gen2, a Fabric pipeline, or a notebook to load your data into a Fabric Lakehouse. Tables must be in Delta format.
Step 3 — Create your Lakehouse and Delta tables
Ensure tables are stored as managed Delta tables and appear under Tables (not Files).
Step 4 — Create a new semantic model in DirectLake mode
Create a new semantic model and select DirectLake as the storage mode, pointing it to your Lakehouse.
Step 5 — Map your tables
Add Lakehouse tables and ensure names match your existing model.
Step 6 — Validate relationships
Rebuild or validate all relationships, paying attention to cardinality and filter direction.
Step 7 — Test your DAX measures
Compare outputs against your Import Mode model. Most DAX works the same, but check:
- Time intelligence
- Row-level security
Step 8 — Understand fallback behaviour
DirectLake may fall back to DirectQuery in some cases. Monitor how often this happens, as too much fallback reduces performance.
Step 9 — Test report performance
Validate load times. Large datasets may introduce framing overhead. Consider pre-aggregations if needed.
Step 10 — Publish and monitor
Deploy and monitor using the Microsoft Fabric Capacity Metrics app. Watch for:
- CPU spikes
- Framing activity
- DirectQuery fallbacks
Pro tip:
Don’t delete your Import Mode model straight away. Keep it as a backup until DirectLake is stable in production.
Should You Migrate?
Not everyone needs to. Import Mode isn’t “wrong”, it’s just not always the best fit anymore.
Move to DirectLake if:
- Your data is already in a Fabric Lakehouse or Warehouse
- Your dataset is getting too large for memory
- You need near real-time reporting
- You want to remove refresh management overhead
Stick with Import Mode if:
- Your data sits outside Fabric (SQL Server, Snowflake, APIs)
- You rely on heavy, complex DAX
- You’re on smaller Premium or Pro capacity
Final Thoughts
DirectLake is one of the biggest architectural shifts in Power BI in years. It’s not just about performance, it changes how storage and analytics work together in Fabric.
Understanding when to use it and how to migrate cleanly is quickly becoming a core skill for Power BI developers.