Why: Materialized View is marked as [recreate view] when upstream incremental model only processes a new time range

[jaogoy]

Hi SQLMesh team,

I’m working on the StarRocks engine adapter and have a question about how SQLMesh is expected to handle Materialized Views (MVs) when they depend on incremental models.

Context

• Execution engine: StarRocks
• I have an incremental model (incremental by time range), depend on a source table.
• A downstream model is defined as a Materialized View on top of that incremental model.
• All model definitions remain unchanged.
• What I do is run the second sqlmesh plan with a new date range, after new data is inserted into the source table.

Observed behavior

• During planning, SQLMesh reports that the downstream MV needs to [recreate view].
• After execution:
  • The MV metadata is recreated (e.g. a new create_time is observed, but with the same hash id).
  • The MV data already contains the newest data.
• In other words, the MV has been totaly recreated, and it refreshes the data IMMEDIATEly (a configure parameter.).

Expected / Questioned behavior

From my understanding, in this case:

• The upstream incremental model’s logical SQL definition does not change.
• Only a new execution time range is processed and new data is appended.

What I would expect (or like to understand if this aligns with SQLMesh design):

1. Should a downstream Materialized View be recreated when the upstream incremental model only refreshes a new time range?

2. If not, is the intended behavior that:

   • The MV remains unchanged and refreshes according to its own configuration, or
   • A REFRESH MATERIALIZED VIEW (or equivalent) is triggered instead of recreating it?

3. Is this behavior controlled by:

   • SQLMesh core (e.g. model change detection / fingerprinting), or
   • The engine adapter (e.g. StarRocks adapter deciding that incremental upstream refreshes are non-breaking for MVs)?

4. Are there existing extension points or recommended patterns for this use case?

I’m also open to the possibility that keeping the downstream MV unchanged may not be consistent with SQLMesh’s design, and would appreciate guidance on the intended semantics here.

Thanks in advance for any insights.