Direct Lake vs import is the first modeling decision for D365 Finance and Operations data on Microsoft Fabric. For most F&O teams on Link to Fabric, the answer is Direct Lake on OneLake over a materialized gold layer of facts and dimensions, with a few small import tables where Excel users or Power Query shaping need them. Import stays the right choice where there is no Fabric capacity, because Direct Lake cannot run on Power BI Pro or Premium Per User. This guide covers how refresh works in each mode, the size limits by F SKU, how modeling and security differ, and what each costs. For what you need to build on top of Link to Fabric first, see what Link to Fabric leaves you to build.
Direct Lake vs import: what each mode actually does
- Import copies the data into the semantic model at every refresh. Queries run against that in-memory copy, and the data is only as fresh as the last refresh.
- Direct Lake reads Delta tables in OneLake. Its refresh, called framing, copies only metadata: it points the model at the latest Delta files, usually in seconds. When a report asks for a column, Direct Lake loads it from OneLake into memory.
- Both modes answer queries from the same in-memory engine. Microsoft says Direct Lake reaches import-like performance once the model is warm; the first queries after a cold start are slower while columns load.
Two kinds of Direct Lake, and why fallback decides between them
| Direct Lake on OneLake | Direct Lake on SQL endpoints | |
|---|---|---|
| Status | Generally available since the March 2026 Power BI update; Microsoft’s recommended option for new models | Available; use it when you depend on SQL analytics endpoint security or need SQL views |
| Sources | Delta tables from one or more Fabric items, including through shortcuts | One Fabric item, through its SQL analytics endpoint |
| Fallback to DirectQuery | Never; past a guardrail the refresh fails and the model cannot be queried until the tables are fixed or the capacity is scaled up | Automatic by default for SQL views, SQL row-level security, or tables over a guardrail; set DirectLakeBehavior to DirectLakeOnly to make queries fail instead |
| Mixing with import tables | Supported in composite models | Not supported in the same model |
Silent fallback is the risk for finance reports: a model that quietly switches to DirectQuery during the close gets slower exactly when controllers use it most. With Direct Lake on SQL, check which tables fall back with the TABLETRAITS function.
What refresh means in each mode
| Import | Direct Lake | |
|---|---|---|
| What a refresh does | Copies all data again, or only recent partitions with incremental refresh | Repoints the model at the latest Delta files (framing), usually in seconds |
| How often | 8 scheduled refreshes a day on Pro, 48 on Premium Per User or Fabric capacity; more through the XMLA endpoint or API on capacity | Automatically when the Delta data changes (on by default), or on your own schedule |
| Time limits | 2 hours per refresh on Pro, 5 hours on Premium Per User or capacity | Not applicable |
| Memory during refresh | A full refresh can use up to double the model’s memory | Low; columns load later, when queried |
| Incremental options | Incremental refresh and hybrid tables | None in the model; append to the Delta tables, and partition large ones by a low-cardinality column |
Two Direct Lake details catch teams out. Loads that overwrite a Delta table force a full cold reload on every refresh. Appends keep the loaded data warm, but merges, updates, and deletes rewrite every Parquet file they touch, so partition a large fact that takes merges, such as InventTrans, whose rows change after posting, by a low-cardinality column like fiscal month; that limits the rewrite and the reload to the months that changed. And VACUUM can delete files a framed model still points to, so run VACUUM only after the model has reframed.
The D365 F&O refresh chain, end to end
Data reaches a report after three waits: the Link to Fabric sync (up to an hour per Microsoft Learn, under 15 minutes in most observed cases with low-latency sync per Microsoft’s Fabric blog), your gold build, and the semantic model. Only the last differs by mode: a Direct Lake reframe takes seconds, while import adds a refresh, capped at 48 scheduled a day on capacity (one every 30 minutes) and 8 on Pro, with more through the XMLA endpoint or the API on capacity. The full chain is in the Link to Fabric guide.
For month-end close, a controlled reframe is often better than automatic updates: turn automatic updates off, and reframe once after each gold build, so a trial balance never shows half of a build.
Why Direct Lake should not sit on the Link to Fabric tables themselves
- They are read-only shortcuts. Dataverse writes and manages the Delta files behind Link to Fabric, so table maintenance such as OPTIMIZE, VACUUM, and V-Order is not yours to run, and Microsoft does not document how those files are laid out. Low-latency sync also writes deletion vectors, which Direct Lake has to apply when it loads data.
- Soft-deleted rows stay in the tables. Deleted F&O rows remain for up to 28 days with IsDelete set, and Direct Lake on OneLake cannot read SQL views, so the filter has to live in a materialized table.
- Microsoft’s guidance agrees. It advises against building Direct Lake models on raw bronze tables, and where the source layout cannot be changed, it suggests a dimensionally modeled, V-Ordered serving layer on top.
So build a gold star schema as Delta tables, with notebooks or materialized lake views. Turn on V-Order for it deliberately, because V-Order is off by default in new Fabric workspaces. Load with appends where you can, partition large facts that need merges, and schedule OPTIMIZE and VACUUM outside the close, because OPTIMIZE rewrites files and sends that data cold. If you use materialized lake views, check that they refresh incrementally; a full refresh rewrites the table.
Sizing GeneralJournalAccountEntry and InventTrans against your F SKU
Direct Lake has guardrails per table and per model. Import’s main limit is model memory:
| F SKU | Direct Lake rows per table | Parquet files and row groups per table | Direct Lake model size on disk | Max memory |
|---|---|---|---|---|
| F2 to F8 | 300 million | 1,000 | 10 GB | 3 GB |
| F16 | 300 million | 1,000 | 20 GB | 5 GB |
| F32 | 300 million | 1,000 | 40 GB | 10 GB |
| F64 | 1.5 billion | 5,000 | Unlimited | 25 GB |
| F128 | 3 billion | 5,000 | Unlimited | 50 GB |
| F256 | 6 billion | 5,000 | Unlimited | 100 GB |
Max memory is not a Direct Lake guardrail: Direct Lake pages columns in and out of memory, so a model can be larger on disk than this figure, with slower queries if it pages heavily. For import it is a hard ceiling, reached only with the large semantic model storage format turned on, and because a full refresh can need double the memory, Microsoft warns that a model near half that size may run out of memory during refresh; incremental refresh avoids that.
Import models are limited to 1 GB in Pro workspaces, and to 100 GB on Premium Per User. In D365 F&O, the general ledger and inventory transaction tables are the ones most likely to pass a row guardrail on F2 to F32. Count their rows on the SQL analytics endpoint before you choose a SKU. If a fact table is too large, aggregate it in the gold layer, move to F64, or import an aggregated table instead of the detail.
Modeling finance reports in each mode
- Keys. F&O natural keys for company-specific records are composite, such as AccountNum or ItemId plus DataAreaId for the company. In Direct Lake, calculated columns cannot be used in relationships, and a duplicate key on the one side makes queries fail, not the refresh, so materialize unique surrogate keys in the gold tables. Import can build them in Power Query or as calculated columns.
- Calculated columns and tables. Import supports both. On Direct Lake on OneLake both are in preview, and calculated columns are evaluated at query time in the user’s context.
- Decoding. Enum labels and financial dimensions have to be decoded somewhere. In Direct Lake that means the gold layer; in import, Power Query can do it, at the cost of refresh time on every run.
- Excel users. Analyze in Excel cannot use hierarchies defined on Direct Lake tables. Put the main account, financial statement, and legal entity hierarchies in small import tables inside a composite model, so PivotTable hierarchies keep working. Named sets and calculated members created in Excel still do not work once a model has Direct Lake tables, so build those as measures in the model.
Security works differently in Direct Lake
By default, Direct Lake reads OneLake with each viewer’s own identity, so every viewer needs read access to the source data, and anyone with that access can read the tables directly, outside the model’s row-level security. Microsoft strongly recommends a fixed identity connection when you use row-level security on Direct Lake. Combine it with row-level security by legal entity in the model. With a fixed identity, viewers need no access to the gold layer, so keep them out of the workspaces that hold the gold lakehouse and the Link to Fabric lakehouse; anyone who can read either one can query its tables outside the model’s row-level security. An import model holds its own copy of the data, so viewers need no lakehouse access at all and see only what its row-level security allows.
What each mode costs
- Licensing. Direct Lake needs a Fabric capacity. On F64 and larger, people with a free license can view reports; below F64, every viewer needs Pro or Premium Per User. The Pro and capacity prices, and the break-even between F32 and F64, are in the Power BI Premium retirement guide.
- Refresh. Microsoft describes an import refresh as consuming significant memory and CPU, and counts it as a background operation, smoothed over 24 hours. A Direct Lake reframe is a low-cost metadata operation.
- Queries. Microsoft classifies report queries, including loading a model when a report opens, as interactive use, which Fabric smooths over minutes rather than hours. It does not say how Direct Lake column loading is billed, so check where that work lands in the Fabric Capacity Metrics app during a close.
- The gold layer. Direct Lake depends on one; an import model can skip it and shape the data in Power Query, which moves that work into every refresh. The notebooks or materialized lake views that build it run as background operations. OneLake storage is billed per GB, and OneLake reads and writes consume capacity units.
- Measure it. Microsoft publishes no capacity comparison between the two modes, so measure both in the Fabric Capacity Metrics app across a month-end close before you commit.
A decision table
| Import | Direct Lake on OneLake | Direct Lake plus import tables | |
|---|---|---|---|
| Licensing | Works on Pro, Premium Per User, or Fabric capacity | Fabric capacity only | Fabric capacity only |
| Largest fact table | Within model memory for your SKU | Within the row and file guardrails for your SKU | Large facts in Direct Lake, small tables imported |
| Freshness | 8 to 48 scheduled refreshes a day, more through XMLA or the API on capacity | Minutes after your gold build | Facts minutes behind; imported tables as refreshed |
| Modeling | Full Power Query and calculated columns | Logic built in the gold layer | Logic in gold, Excel hierarchies in import tables |
| Team skills | Power BI and Power Query | Fabric data engineering and Power BI | Both |
| Capacity use | Heavy background refresh | Light refresh, query-time loading | Mixed |
If your F&O data is not on Link to Fabric
- Azure Synapse Link with CSV output: use import, or convert the files to Delta first, because Direct Lake reads only Delta tables.
- Azure Synapse Link with Delta output: use import, or test Direct Lake through a OneLake shortcut to the Delta folders. Either way, plan the move: the option closed to new customers on October 15, 2026, and existing users must move to CSV output or Link to Fabric by December 2027.
- BYOD: use import or DirectQuery against the database.
- Export to Data Lake: it stops on November 30, 2026; see the migration guide.
Where Metrixs fits
Metrixs runs in your own Microsoft Fabric environment on Link to Fabric or Azure Synapse Link, and adds its data model and 150+ pre-built Power BI reports, with 1,200+ metrics and 250+ KPIs. On the Standard plan, reports use Direct Lake and refresh every 15 to 30 minutes, depending on data volume, the number of reports, and Fabric capacity; the Basic plan refreshes nightly. See Microsoft Fabric for D365 F&O for how it fits together, or request a demo and see if you qualify for a free 6-month trial.
FAQs
1. Is Direct Lake faster than import?
Not usually; once warm, the two perform about the same. Both modes answer queries from the same in-memory engine, and Microsoft says Direct Lake reaches import-like query performance once the model is warm. The first queries after a reframe or a cold start are slower, because Direct Lake loads the columns a query needs from OneLake at that moment.
2. Can Direct Lake run on Power BI Pro or Premium Per User?
No. Direct Lake needs a Fabric capacity (an F SKU, or a legacy P SKU). Pro and Premium Per User workspaces can host import and DirectQuery models only.
3. Does Direct Lake on OneLake fall back to DirectQuery?
No. Direct Lake on OneLake never falls back. If a table exceeds a guardrail for your capacity, the refresh fails and the model cannot be queried until the Delta tables are brought back within limits or the capacity is scaled up. Fallback to DirectQuery applies only to Direct Lake on SQL endpoints.
4. Can I use incremental refresh with Direct Lake?
No. Direct Lake has no incremental refresh or model partitions, because its refresh only repoints the model at the latest Delta files. Load the Delta table with appends where you can, and partition large facts by a low-cardinality column, such as fiscal month, so merges rewrite only the partitions that changed.
5. Can I build a Direct Lake model directly on the Link to Fabric tables?
You can point a model at them, but Microsoft advises against building Direct Lake on raw tables. The Link to Fabric tables are read-only shortcuts with soft-deleted rows and encoded dimensions, so build a materialized gold layer of facts and dimensions and point Direct Lake at that.
Sources
All pages below were checked on October 19, 2026.
- Direct Lake overview
- Power BI Desktop update archive (Direct Lake on OneLake general availability, March 2026)
- How Direct Lake works
- Develop Direct Lake semantic models
- Understand Direct Lake storage
- Direct Lake security integration
- Table maintenance and optimization for Direct Lake
- Delta table optimization and V-Order
- Calculated columns in Power BI
- Microsoft Fabric concepts and licenses
- Large semantic models in Power BI
- Data refresh in Power BI
- Incremental refresh in Power BI
- Fabric operations: background and interactive
- Fabric throttling and smoothing
- OneLake consumption
- Create a Dataverse shortcut
- Configure your environment and link to Microsoft Fabric
- Microsoft Fabric link FAQ
- Microsoft Fabric Updates blog: what’s new for Dataverse Fabric link, July 2026
- Choose finance and operations data in Azure Synapse Link for Dataverse
- Materialized lake views overview
- Azure Synapse Link Delta Lake option deprecation
Senior Business Intelligence Architect with 22 years of experience designing enterprise analytics and data platforms. Focus areas include Power BI, real-time analytics, and large-scale BI architecture across the Microsoft data stack.
