Memory hook: Refresh defines visibility; storage mode defines the query path.
Must remember
Import loads data into the model; DirectQuery queries a supported source; Direct Lake reads supported Delta data from OneLake. Composite models combine supported storage/source configurations. Choose according to freshness, size, source load, latency and security requirements, then test actual behavior.
Direct Lake on OneLake accesses OneLake directly and does not fall back to DirectQuery. Direct Lake on SQL analytics endpoint uses that endpoint for discovery/security integration and can fall back for supported cases when fallback is enabled. SQL views, security requirements or guardrails can change the path. Do not diagnose every Direct Lake slowdown as an Import refresh issue.
Direct Lake framing updates which table data the model references; loading needed columns into memory is a separate operation. Automatic updates, explicit refresh and source availability affect freshness. Capacity limits and model design still matter even when there is no traditional full Import copy.
For Import incremental refresh, define a date/time partitioning policy with appropriate range parameters and source filtering. Historical and refresh windows have different purposes. Confirm folding or efficient source execution; otherwise a partitioned policy may still scan too much data. Detecting changes is not the same as universally detecting every hard deletion.
Large semantic-model storage format supports larger models on appropriate capacity; it does not fix excessive cardinality or inefficient DAX. Measure visual/query duration, refresh time, memory pressure and capacity contention. Remove unnecessary columns, use suitable types and grain, simplify relationships and optimize the expensive query before buying capacity.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Direct Lake with no SQL fallback | Direct Lake on OneLake, checking its own supported limits. |
| Historical Import data changes rarely | Incremental refresh with a tested partition policy. |
| A Direct Lake query unexpectedly hits SQL | Check whether the SQL-endpoint flavor fell back. |
Traps
- Direct Lake does not mean unlimited memory or zero freshness management.
- Increasing capacity can hide an inefficient query without correcting it.
Active recall
1. Do both Direct Lake flavors support fallback?
No. OneLake does not; the SQL-endpoint flavor can when enabled and applicable.
2. What does framing do?
Updates the data snapshot referenced by the model rather than copying every row through a traditional Import refresh.
3. Why use incremental refresh?
To avoid repeatedly reprocessing unchanged historical partitions.
4. Why check folding?
A source scan may remain expensive if partition filters are not pushed down efficiently.
5. What should precede capacity scaling?
Measure and optimize model, query and concurrency bottlenecks.