Power BI / Advanced: performance and governed delivery / Lesson 13

Storage modes and query boundaries

Choose a semantic-model access pattern from freshness, governance and workload requirements rather than assuming one mode is universally faster or current.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Compare Import, DirectQuery and live model reuse.
Explain composite-model and Direct Lake assumptions.
Separate query latency, source freshness and access enforcement.

Start from required behavior

Storage mode determines important data and query boundaries, but the business requirement comes first. Define acceptable data age, response time, source load, data residency and security behavior. Import loads a copy into the semantic model and needs a deliberate refresh contract. DirectQuery sends relevant work to a supported source at query time, introducing source and connectivity dependencies. A live connection can reuse an existing governed semantic model instead of rebuilding its logic locally. These choices do not change the need for correct grain, relationships and measures. A mode label alone cannot establish that a displayed result is current or authorized.

Compare snapshots with source queries

The first record contrasts a loaded import snapshot with a later source state. A DirectQuery result can still be influenced by source update delays, caching, report refresh behavior and query failures; it should not be advertised as automatic zero-latency real time. Import can provide responsive analysis while accepting a documented freshness window. Evaluate the actual workload rather than switching modes to hide a slow measure. No source connection is created in this example. The record states analytical assumptions and deliberately omits credentials, server names and executable connector instructions.

text Two data cutoffs, not a benchmark

import copy at cutoff T1: synthetic revenue70
source at later cutoff T2: synthetic revenue90
report questions: which cutoff, which mode, which completed operation?
separate claims: freshness, latency, source access and calculation correctness

The values are invented teaching states. They are not captured Import or DirectQuery results.

Understand composite and Dual design

A composite model can combine supported table modes or supported multiple DirectQuery sources under documented constraints. Dual storage can let an eligible table behave as Import or DirectQuery depending on the query path. These are modeling decisions with relationship and consistency implications, not a universal acceleration switch. Imported dimensions can become stale relative to directly queried facts, and cross-source relationships can have different limitations from a simple import star. List each table’s mode and source group and review the exact feature combination against current documentation. Avoid assuming every connector, function or security pattern is supported in every combination.

Place Direct Lake in context

Direct Lake is a Fabric semantic-model table storage option using supported Delta data in OneLake. Its framing, memory loading and feature-specific behavior differ from importing a full copy or federating DirectQuery work. This lesson does not provision Fabric, choose a capacity or promise a performance multiplier. Consult the actual Direct Lake variant, source layout, security model and current limitations before design. The second program merely compares two public numeric snapshots. It proves that a retained copy can differ from a later source value, not how any Power BI mode will cache, refresh or execute.

python Synthetic snapshot difference

import_copy = [20, 20, 30]
later_source = [20, 20, 30, 20]
print(sum(import_copy))
print(sum(later_source))
print(sum(later_source) - sum(import_copy))

Expected output

70
90
20

70,90 and20 describe these lists only. No model mode or source engine is exercised.

Write a mode decision record

Record data age, latency target, source capability, expected concurrency, security ownership, transformation requirements and feature restrictions. Explain how refresh or query failures appear to consumers and who owns recovery. Licenses, capacity and tenant settings can affect available features; current prices and universal size limits are outside this lesson. The course runs no source query, gateway or cloud operation. A useful decision is a justified contract with explicit remaining tests, not a claim that DirectQuery is always current or that Import is always too large. Reassess the choice when data shape, governance or workload changes.

Common errors and fixes

DirectQuery is described as guaranteed real time

Why it happens: Source latency, caching and report behavior were ignored.
How to fix it: Define an observed freshness contract and supported query path.
Prevent it next time: Keep mode and data-cutoff evidence separate.

Dual is enabled without reviewing relationships

Why it happens: A mode feature was treated as a universal speed switch.
How to fix it: Review eligible tables, query paths and cross-source consistency.
Prevent it next time: Document table modes and source groups in the model inventory.

A Direct Lake assumption is copied into a non-Fabric model

Why it happens: Product, source and capacity boundaries were omitted.
How to fix it: Check the exact supported storage option and environment prerequisites.
Prevent it next time: Version feature assumptions instead of relying on a broad mode name.

Check your understanding

1. Why does a later source total90 not make an Import total70 mathematically wrong?

Show worked solution

They can represent different valid data cutoffs. The question is whether70 meets the promised freshness and inclusion contract. Verify copy identity and last usable data, then assess the expected refresh path. Correct arithmetic over stale data can still be unsuitable for a current business decision.

2. What must be reviewed before mixing imported dimensions and DirectQuery facts?