Thanks for the clarification. From what I understand, this is essentially approach 2, but instead of implementing custom incremental logic, we rely on the Materialized View engine to detect which groups changed and recompute only those.

To make it concrete, let’s say I create a materialized view with this query:

SELECT
customer_id,
date_trunc('month', timestamp) AS month,
median(value)
FROM time_series_table
GROUP BY
customer_id,
date_trunc('month', timestamp)

In this scenario, my expectation would be that during a refresh, Databricks automatically detects which (customer_id, month) combinations were affected by new or updated data and only recomputes those groups.

Can you confirm if that’s indeed how it works internally?

In other words, does the Materialized View engine track which group keys changed and incrementally recompute only those, without custom logic on our side?

Also, are there situations where the Materialized View ends up scanning or recomputing significantly more groups than strictly necessary (e.g. falling back to a broader recomputation or even full refresh)? Is there anywhere I can inspect the number of groups recomputed in a refresh?

That would really help to validate whether we can fully rely on the Materialized View for this pattern at scale.