Warehouse Views: Should Heavy Views Be Materialized for Direct Lake?

Several warehouse views timing out usually means a couple of shared trunks and many dependents. Teams that rewrite every leaf, or jump straight to a new platform, often miss the cheap win: materialize the consolidations everything else hangs from.

Use a layered playbook. Drop orphans. Apply cheap predicate and join rewrites. Then materialize the two or three heavy consolidations. Measure with the same harness before and after. Document what is a view versus a managed table so CI/CD stays honest.

Figure 1. Trunks before leaves. Materialize the shared consolidations. Keep dependents thin. Drop orphans that still tempt copy-paste.

Context and constraint

A common failure: every timeout spawns a new "optimize this view" ticket. The leaves get prettier. The trunk still scans the same giant consolidations on every call. Once the trunks are materialized, dependents that looked hopeless become boring again.

Orphan views waste attention. Cheap rewrites (filters pushed down, dead joins removed) should happen before new infrastructure. Materialized consolidations make gold near-instant without rewriting every consumer. Measurement without a stable harness invents folklore. Docs that lie about view versus table create deploy surprises.

Figure 2 is the Fabric warehouse surface. When dependents time out, start with the graph, not with a leaf rewrite ticket.

Figure 2. When dependents time out, materialize the trunk consolidations first instead of rewriting every leaf view. Source: Microsoft Learn: data warehousing in Fabric.

Figure 3 is the SQL analytics endpoint surface. Measure with the same harness before and after, and keep inventory honest about what is a view versus a managed table.

Figure 3. Measure with the same harness before and after. Document view versus managed table so CI/CD stays honest. Source: Microsoft Learn: data warehousing in Fabric.

Design

1. Map timeouts to trunks

Profile which objects burn time. Walk dependents upward until you find the consolidations shared by many failures. Fixing a leaf that selects from a slow trunk is theater. Publish a short graph in the repo so the next incident does not start from zero.

2. Drop orphans before cleverness

If nothing consumes a view, delete or archive it. Orphans still appear in search, still tempt copy-paste, and still confuse capacity reviews. Removing them is performance work with a delete key.

3. Try cheap rewrites first

Push predicates closer to base tables. Remove unused joins and columns. Replace SELECT * stacked three deep. These changes are reversible and teach the real cost model. Do them with parity checks so "faster" does not mean "different."

4. Materialize the shared consolidations

When two or three objects dominate CPU and every gold path reads them, materialize on a schedule that matches freshness needs. Dependents stay views. Consumers keep their contracts. You pay storage and refresh to buy predictable read latency. For Direct Lake paths, a table based on a non-materialized SQL view is a known fallback risk; materializing the trunk is how you keep read latency honest.

Figure 4 is the order that keeps storage and refresh from sprawling before you have earned them.

Figure 4. Layered timeout playbook. Orphans and cheap rewrites come before materialization. The harness and inventory come with the change, not after.

5. Measure with one harness

Same queries, same parameters, same concurrency assumptions before and after. Capture wall-clock and capacity signals you actually operate on. Anecdotes from laptops are not release evidence. Store results next to the change.

6. Label views versus managed tables in CI/CD

Deployment docs and inventory files should say which objects are materialized. Restoring a trunk as a view by accident is an outage dressed as a successful deploy. Be explicit in naming or metadata so humans and pipelines do not guess.

Figure 5 is the contract that keeps "felt faster" and secret materializations from becoming folklore.

Figure 5. One harness for before and after. Honest inventory for CI/CD. Secret materializations are how support expects live compute and gets lag instead.

Freshness is part of the materialization contract

A materialized trunk is only a win if consumers know how stale it can be. Publish the schedule, the watermark, and the failure behavior when refresh skips. If a dependent needs tighter freshness than the trunk offers, that is a product decision: accept lag, pay for a narrower live path, or split the consolidation. Do not hide lag behind a view name that implies live warehouse compute.

Choosing the two or three trunks

Rank candidates by shared dependent count times average cost. Resist materializing a politically important leaf that nothing else uses. Resist skipping an ugly consolidation because the SQL is embarrassing; embarrassment is not a cost model. After materialization, re-profile. Sometimes a second-tier object becomes the new trunk. Repeat once. Stop before you reinvent the entire warehouse as tables without a reason.

Communication with report owners

Tell consumers when a trunk becomes materialized and what freshness to expect. Otherwise they will file "warehouse is wrong" tickets that are actually "refresh has not landed." A short note in the semantic model description or a workspace announcement beats a surprise. If a VIP report needs live compute against the trunk, call that out as an exception with cost and risk, not as a silent revert to a view.

Parity still applies when you materialize for speed

A faster trunk that changes grain is not a win. Keep the same reconciliation mindset you use for MLV migration: row counts, keys, and a few critical aggregates before you point dependents at the table. Performance projects that skip parity create silent semantic releases. Call the parity job part of the materialization PR, not a follow-up wish.

Failure modes

Leaf-first optimization. Pretty SQL on top of a furnace.

Platform hop as first move. New engine, same graph mistake.

Materialize everything. Storage and refresh sprawl; nobody knows the freshness story.

No harness. Every change "felt faster."

Secret materializations. Inventory still says "view"; support expects live compute.

Skipping orphan cleanup. Capacity and cognition both leak.

What to copy / what not to copy

Copy

• Timeout triage starts with a dependency map and trunk identification.
• Orphans are removed before net-new optimization projects.
• Cheap rewrites precede materialization and platform changes.
• Only shared heavy consolidations are materialized by default.
• Before/after results use a shared query harness retained as evidence.
• Inventories distinguish views from managed/materialized tables for CI/CD.

Do not copy blindly

Materialization adds refresh jobs and storage. Timeouts add user pain and shadow extracts. Cheap rewrites take analyst time; they often remove the need for wider changes. Strict inventory discipline annoys people who like renaming quietly. Quiet renames break dependents. Harness maintenance is real work; folklore maintenance is endless work.

Primary references: Fabric data warehousing, Direct Lake overview (SQL views and fallback), and warehouse performance / query insights guidance on Microsoft Learn. Pair platform advice with your dependency map so optimization follows edges, not opinions.

Find the trunks. Drop dead weight. Rewrite cheaply. Materialize the shared consolidations. Measure. Leave the leaves thin. Timeouts become a schedule problem you can name, not a weekly panic about "the warehouse."