When warehouse views time out, materialize the trunk not the leaves

Nine warehouse views timing out usually means two trunks and seven 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. When dependents time out, materialize the trunk consolidations first instead of rewriting every leaf view. Source: Microsoft Learn: data warehousing in Fabric.

Figure 2. 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.

I learned this on estates where every timeout spawned a new "optimize this view" ticket. The leaves got prettier. The trunk still scanned the same giant consolidations on every call. Once we materialized the trunks, dependents that had looked hopeless became boring again.

The core idea

Performance work should follow the dependency graph. Materialize trunks; keep leaves thin.

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.

A model that stays explainable

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.

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.

Failure modes I design against

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.

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.

Trade-offs

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.

What I would put on an ADR

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

Primary references: Fabric warehouse performance and query insights guidance on Microsoft Learn. Pair platform advice with your dependency map so optimization follows edges, not opinions.

Closing

When everything is slow, not everything is the problem.

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."