2 posts tagged with "SQL"

Moving a handful of warehouse views to Materialized Lake Views is a rewrite. Moving hundreds is a program. Teams that treat the long tail like a weekend notebook usually discover dependency order the hard way: gold breaks, silver thrashes, and bronze shortcuts were never registered as the real contract.

Frame the work as bronze to silver to gold with gates. Count the estate. Order by dependency. Prove a representative POC. Then convert with per-view notebooks so blast radius stays local. Success is parity plus runtime, not "the portal shows an MLV."

Figure 1. MLV migration is a program across bronze, silver, and gold. Gates belong between layers, not as a weekend cutover wish. Source: Microsoft Learn: medallion lakehouse architecture.

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.