Most Power BI teams are picking a storage mode by gut feel, and it is quietly costing them money. Import feels safe. DirectQuery feels real-time. Direct Lake feels modern. None of those instincts survive contact with a Fabric capacity meter, a 200-million-row fact table, or a Copilot query that fans out into the semantic model twelve times per user prompt.

Microsoft Fabric changed the calculus of this decision. Direct Lake introduced a third path that reads Delta tables directly from OneLake with no data movement, promising near-Import performance with DirectQuery-level freshness. That promise is real, but conditional. Choose wrong and you inherit slower dashboards, higher Fabric Capacity Unit consumption, a governance headache, and a semantic layer that is not ready for the agentic workloads about to hit it.

This is a plain-language Power BI storage mode decision tree for enterprise architects who need to defend a choice in an architecture review, not memorize documentation.

The three modes in plain language

Import loads a compressed copy of your data into the VertiPaq engine, in memory. Refreshes are scheduled events. Queries hit RAM. It is fast, predictable, and forgiving of messy source data or complex DAX. Its ceiling is model size, refresh windows, and freshness lag.

DirectQuery stores no data. Every visual translates DAX into a query against the source system in real time. Freshness is immediate. Performance depends entirely on the source, and every user click puts load on that source. It is a targeted tool, not a default.

Direct Lake, according to Microsoft Learn, reads Delta-Parquet files directly from OneLake into VertiPaq memory on demand. There is no scheduled refresh. Instead, a lightweight operation called framing updates the model's pointer to the latest Delta table version, and columns are loaded into memory through transcoding the first time they are queried. When it works, you get Import-class query speed with lakehouse-fresh data. When it does not, the model silently falls back to DirectQuery, and your users notice.

The Power BI storage mode decision tree

Skip the feature comparison table. In practice, the choice comes down to five sequential questions. Answer them in order and stop at the first mode that fits.

1. Where does the data live? If it is already in OneLake as well-formed Delta tables, Direct Lake is a candidate. If it lives in an on-premises SQL Server, a third-party SaaS API, or a source with strict data-residency constraints, Direct Lake is off the table. Consider Import or DirectQuery.
2. What is the freshness SLA? Sub-minute freshness against a transactional source points to DirectQuery. Minutes-to-hours freshness against a lakehouse points to Direct Lake. Daily or intraday freshness against curated data points to Import.
3. How complex is the model and DAX? Heavy calculated columns, complex many-to-many relationships, and DAX that leans on advanced VertiPaq behavior favor Import. Direct Lake supports calculated columns only in limited scenarios and does not support calculated tables. Complex models on Direct Lake tend to trigger fallback.
4. What Fabric SKU do you have? Direct Lake's memory residency model needs headroom. On F2 to F16 capacities, a large fact table can evict itself under normal load. If you cannot right-size the capacity, Import on a Pro or PPU workspace is often the more honest answer.
5. How mature is your Delta table hygiene? Direct Lake performance depends on V-Ordered Parquet files, sensible file sizing, and disciplined OPTIMIZE and VACUUM. If your medallion architecture is still being built, defer Direct Lake for that workload and use Import against the gold layer.

The first mode that satisfies every question above it is the right answer. In our observed BabyBots implementations, roughly one workload in three that teams initially slot for Direct Lake ends up better served by Import once question three or five is answered honestly.

Direct Lake tradeoffs the docs bury

The Microsoft documentation is accurate. It is also easy to skim past the parts that matter most in production.

Silent DirectQuery fallback. By default, Direct Lake models are configured with Automatic fallback behavior. When a query exceeds a guardrail (model size, row count, unsupported feature, memory pressure), the engine transparently switches that query to DirectQuery against the SQL analytics endpoint. As Sandeep Pawar of the Microsoft Fabric CAT team documents, this fallback is silent, per-query, and can mask a model that is not actually running on Direct Lake at all. Users see slower dashboards. Admins see higher CU consumption. Nothing in the report tells them why.

Memory residency is a spectrum, not a switch. Per Microsoft Learn, Direct Lake columns move through cold, semiwarm, warm, and hot states. A cold column has never been queried and must be transcoded from Parquet on first access. That first query pays a latency tax. Under memory pressure, columns get evicted back toward cold. On smaller capacities, the same executive dashboard can be fast at 9:00 AM and sluggish at 9:07 AM.

Framing and transcoding consume Fabric Capacity Units. Framing is cheap. Transcoding is not free. Every table write that invalidates the frame triggers reload work on next query. High-frequency Delta writes against a wide fact table can burn CUs quietly, and unlike Import refresh, there is no scheduled window to budget against.

DirectLakeOnly is a governance tool, not a limitation. Setting fallback behavior to DirectLakeOnly forces the engine to fail queries that would otherwise silently degrade. That is what you want in production. It surfaces problems during testing instead of on Monday morning.

Direct Lake is the right default for new Fabric workloads, Import is still the right answer for complex DAX and small-to-mid capacity tenants, and DirectQuery is a scalpel, not a strategy.

A Direct Lake readiness checklist

Before promoting any workload to Direct Lake, walk this checklist. Every item is a real failure mode we have watched blow up in production.

• V-Order is applied on every Delta table the semantic model touches. V-Order is a write-time optimization that aligns Parquet layout with VertiPaq's read pattern. Without it, transcoding is slower and column compression is worse.
• Parquet file sizing is sane. Aim for files in the hundreds of megabytes, not thousands of tiny files. Run OPTIMIZE on a schedule. Small-file problems translate directly into transcoding latency.
• Medallion architecture is enforced. Semantic models point at gold. They do not point at bronze or raw. This is a non-negotiable governance boundary.
• Capacity memory is sized for warm residency. If your working set does not fit comfortably in the SKU's memory budget with headroom, you will thrash. Right-size the SKU or shrink the model.
• Row-level security is tested against the SQL analytics endpoint. Fallback queries route through the endpoint, and RLS behavior can differ from what your VertiPaq tests suggest.
• Fallback behavior is set to DirectLakeOnly in production. Fail loud in test. Never let silent fallback ship to users.
• Framing frequency is aligned to write cadence. Frame after your ETL commits, not on an arbitrary clock.

When NOT to use Direct Lake

Naming the anti-patterns is more useful than another list of features. Avoid Direct Lake when any of the following are true.

• High-cardinality dimensions dominate the model. Wide string columns with millions of distinct values compress poorly, transcode slowly, and stress memory residency.
• Complex calculated columns and calculated tables are core to the design. These are Import strengths. Rewriting them as upstream Delta transformations is often the right call, but it is real engineering work.
• Sources are not in OneLake and shortcuts are impractical. Direct Lake does not read arbitrary sources. If the data lives elsewhere and cannot be mirrored or shortcut in, choose Import or DirectQuery.
• Self-service analysts own the model. Direct Lake rewards disciplined data engineering. If the semantic model is being built ad hoc in Power BI Desktop by a business analyst, Import protects them from failure modes they cannot diagnose.
• You are on a small SKU without Delta hygiene. An F2 with unoptimized Parquet is a support ticket waiting to happen.

The mid-market reality: F2 to F16 and PPU

Most published guidance quietly assumes F64 or higher. That is not where most mid-market Fabric adoption is happening. On F2 through F16 capacities, Direct Lake is viable but narrow. Memory ceilings are tight, background operations compete with interactive queries, and a single poorly-written report can smooth-throttle the entire capacity.

For mid-market tenants, the pragmatic pattern is Import against a curated gold layer, published to a PPU workspace or a small Fabric SKU, with Direct Lake reserved for one or two flagship workloads where the freshness case is unambiguous. Reach for Direct Lake broadly only when you can commit to F32 or higher and a data engineering owner for the Delta layer. Below that line, Import is not a compromise. It is the correct answer.

Migration playbook: Import and Direct Lake side by side

You do not need to migrate. You need to co-exist deliberately. The pattern that works:

1. Inventory workloads by decision-tree answer. Not every report needs to move. Most should not.
2. Pilot one high-value, well-scoped workload on Direct Lake. Pick something with clean gold-layer Delta tables, a clear freshness benefit, and a tolerant user base.
3. Use composite models to bridge. A Direct Lake fact table can join a small Import dimension where a calculated column is unavoidable. Composite is not an afterthought. It is often the correct design.
4. Instrument CU consumption before and after. Compare refresh CUs on the old Import model against framing, transcoding, and query CUs on Direct Lake. Direct Lake is not automatically cheaper, especially under agentic query patterns.
5. Sunset legacy Import models only when the Direct Lake version has passed a full month of production load. Keep the Import model as a fallback until then.

What this means for Copilot and AI agents

This is the part the current market is under-discussing. Copilot and Fabric Data Agents do not query semantic models like humans do. A single natural-language prompt can fan out into a dozen DAX queries, each of which pays the storage-mode tax. On Direct Lake, that means transcoding cold columns, potentially triggering fallback, and consuming CUs per invocation that scale with usage rather than with scheduled refresh. As Microsoft's Power BI agentic overview makes clear, semantic models are becoming the primary interface between enterprise data and the agent layer.

Two practical implications. First, warm-state residency matters more in an agentic world than a human one. Agents do not respect your business hours, and a cold column at 3:00 AM is a failed answer to a CFO's morning prompt. Second, capacity planning must now include agent-query volume as a first-class input, not an afterthought. Storage mode is no longer only a BI decision. It is an AI-readiness decision.

The BabyBots recommendation

Storage mode is an operating-model decision disguised as a technical one. Choose it deliberately.

• If your data is in OneLake, your Delta layer is disciplined, and you are on F32 or higher: choose Direct Lake, set fallback to DirectLakeOnly, and instrument CU consumption from day one.
• If your DAX is complex, your analysts own the model, or you are on a small SKU: choose Import against a curated gold layer. It is not a legacy pattern. It is the pragmatic answer.
• If you need sub-minute freshness against a transactional source you cannot land in OneLake: choose DirectQuery for that specific workload only, and budget the source-system load.
• If Copilot and Fabric Data Agents are on the roadmap: treat storage mode as an AI-readiness decision and prioritize warm-state residency, DirectLakeOnly configuration, and CU headroom above headline speed benchmarks.

The teams that will look smart in eighteen months are not the ones that picked the newest mode. They are the ones that picked the right mode per workload, wrote down why, and built a semantic layer their agents can query without lighting the capacity meter on fire.