This is the second post in a three-part series exploring the mechanics of Materialized Lake Views. The goal is to help you understand how they work and whether they make sense for your environment. What they are, when they help, and when they fall short.

Now, if you’ve decided MLVs might be worth considering, the next question is simple but crucial:

Should I actually use an MLV here, or would something else be a better fit?

This is a guide for data engineers who need to make architectural decisions about when MLVs belong in your design—and when they don’t. It’s about choosing deliberately, not just defaulting to the newest tool.

Declarative vs Procedural

Before we talk about MLVs specifically, you need to understand the fundamental tradeoff they represent.

Declarative thinking: “Here’s what I want. You (the system) figure out how to deliver it efficiently.”

Procedural thinking: “Here’s exactly how to build this. I control each step.”

MLVs are declarative. You define a transformation in SQL, Fabric handles scheduling, dependency ordering, and refresh decisions. You don’t have to choreograph the work—Fabric can.

Notebooks and pipelines are procedural. You write the steps, you control the order, you decide when things run.

This is the root of every design decision that follows.

MLVs vs Notebooks:

This is probably the most common comparison you’ll make.

Use a notebook if:

• You need step-by-step control over execution order
• The transformation is exploratory or one-off
• You’re rapidly iterating on logic
• You need to mix multiple languages or tools
• You want fine-grained error handling within the transformation
• The logic is complex and benefits from imperative clarity

Use an MLV if:

• The transformation is stable and reusable
• You want Fabric to manage dependencies automatically
• You’re comfortable giving up procedural control for operational simplicity
• The logic is clear enough to express as a single SQL statement (or a few chained MLVs)
• You don’t need to inspect intermediate results manually
• You want lineage and refresh history built in

The tradeoff:

• Notebooks are more flexible. You can do almost anything.
• MLVs are less flexible, but they shift operational burden to Fabric. That’s the point.

If you’re developing a notebook mainly to define and run one straightforward transformation, an MLV is probably the cleaner fit. But if you need to step through the logic, branch based on conditions, or add real error-handling and troubleshooting inside the flow, stick with a notebook.

Intent vs Storage

This one gets confused often, so let’s be direct.

A table is storage. It holds data. It’s passive.

A Materialized Lake View is a contract. It’s a persisted transformation that refreshes on your defined schedule. It’s active.

Use a table if:

• You’re storing raw data or a final dataset
• The content isn’t derived from a transformation
• You don’t need automatic refreshes
• You’re building a data product that others will query directly

Use an MLV if:

• The dataset is the output of a transformation
• You want Fabric to refresh it automatically based on your schedule
• You want to signal intent: “This dataset is maintained by this SQL logic”
• You benefit from lineage that shows exactly how the data was derived

The practical difference:

Creating a table from a Spark job and then manually writing a transformation that populates it is procedural. Defining an MLV that does both—persists and transforms—automatically is declarative.

A table can be updated by anything. An MLV can only be updated by its defining transformation. That constraint is a feature when you want a single source of truth.

When MLVs Fit

MLVs tend to be a good fit when these align:

You have a clear transformation boundary.
The logic is well-defined and can be expressed declaratively. It’s not a series of interdependent steps.

The output is reused.
Multiple reports, models, or downstream processes consume it. A shared definition beats scattered copies.

Refresh economics make sense.
The cost of refreshing the MLV (on your schedule) is acceptable and ideally lower than computing the result every time it’s queried.

The refresh pattern is predictable.
Your data changes in a way that MLV’s optimal refresh can handle. Mostly append? Good. Heavy updates and deletes? Risky.

Operational simplicity has value.
You’d rather have Fabric manage dependencies and scheduling than hand-roll orchestration.

Lifecycle stability matters.
You’re comfortable treating the MLV as a maintained asset, not a scratchpad. Team members will be added and removed; the MLV should outlive individual engineers.

Common Mistakes

Mistake 1: Using MLVs for one-off exploratory work
MLVs are for things that matter operationally. If you’re testing a hypothesis or building a temporary report, use a notebook. When the work stabilizes and becomes reusable, then think about MLVing it.

Mistake 2: Chaining too many MLVs together
Three MLVs in a line? Maybe okay. Seven? You’ve probably reinvented a procedural pipeline in a declarative wrapper. Consider whether a notebook would be clearer.

Mistake 3: Mismatching the refresh schedule to the actual need
An MLV that refreshes hourly but is queried once a week is wasteful. An MLV that refreshes daily but needs fresh data every hour doesn’t meet requirements. Think about actual usage patterns, not just “sounds reasonable.”

Mistake 4: Treating an MLV like a table
An MLV is a contract. If the upstream logic changes, the MLV changes. If you need to perform ad-hoc inserts or updates, you’ve chosen wrong. Use a table.

Mistake 5: Overestimating refresh efficiency
Teams often assume incremental refresh will be automatic. It won’t—not without careful design. If your data has updates and deletes, expect full refreshes. Plan accordingly.

Mistake 6: Forgetting about maintenance burden
An MLV is a maintained artifact. If upstream schemas change, the MLV breaks. If dependencies shift, lineage gets messy. Budget for ongoing ownership, not just creation.

Lifecycle and Ownership

Here’s something rarely discussed: how does this artifact age?

An MLV that worked well for two years can become a liability if:

• Upstream data sources change structure or disappear
• The refresh schedule no longer matches actual usage patterns
• The logic becomes too complex to maintain
• Teams turn over and nobody remembers why it exists

Questions to ask at design time:

• Who explicitly owns this? Be clear. Not “the team”, but an actual person or specific team.
• What happens if an upstream source breaks?
• How will we know if this is still being used in two years?
• What’s the retirement plan if we don’t need it anymore?
• Would a junior engineer be able to understand and modify this logic?

An MLV that answers these questions at creation time is far more likely to be useful at year three.

When MLVs Don’t Fit

However, don’t use an MLV if:

• The transformation is exploratory or temporary
• You need procedural control over execution steps
• The logic changes constantly
• Updates and deletes are frequent and full refreshes are unacceptable
• The output isn’t reused
• You need to do something a notebook can do and it would be simpler
• Cross-lakehouse dependencies are critical to your design
• You need GA-level operational guarantees today (it’s in preview as of writing this)

In most of these cases, a notebook or a hand-rolled pipeline is the right tool. That’s a valid architectural choice.

The Decision

Therefore, before you create an MLV, ask yourself:

1. Is this output reused? (If no, probably a notebook.)
2. Can I express this as clear, stable SQL? (If no, probably a notebook.)
3. Do I benefit from Fabric managing dependencies? (If no, maybe a table + notebook.)
4. Will this exist and change for years? (If no, probably a notebook.)
5. Is ownership and maintenance clear? (If no, don’t create it.)

If you answer yes to most of these, an MLV is likely the right abstraction.

The Takeaway

Finally, Materialized Lake Views aren’t superior to notebooks or tables. They’re fundamentally different.

Use an MLV when you want:

• A persisted, automatically-refreshed output of a transformation
• Operational simplicity over procedural control
• A clear, auditable contract about how data is derived

Skip MLVs when you need:

• Flexibility over simplicity
• Procedural control
• Something that’s temporary or exploratory

The best architecture isn’t the one that uses the newest features. It’s the one where each piece (MLVs, notebooks, tables, etc..) does the job it’s best suited for, and nobody has to struggle to explain why it exists.