direct lake semantic model and DBT materialization - breaks model

Hi Janzze96 

Yes, you are correct in that the direct like semantic model is bound to the tables and files when it is created. So if those files, all tables are deleted the semantic model will no longer work successfully. And this is how it works as by design. So I would highly recommend incremental learning or truncate and reload of the tables but not to delete the tables. That should overcome your issue.

Hi Janzze96,

I have seen the same general pattern when a dbt run performs a destructive rebuild of a table that is already being consumed by a Direct Lake semantic model.

Direct Lake refresh is essentially a metadata reframing operation against the Delta tables in OneLake. It can pick up new data and table metadata changes, but it cannot provide continuity during a period where the underlying table has been dropped and recreated. That also explains why increasing the semantic model refresh frequency does not really solve this - the table temporarily stops existing as the same stable source object.

For tables exposed to Direct Lake, I would treat the table itself as a persistent serving contract and avoid ordinary drop-and-recreate materialization during routine production runs.

The approach I would use is:

• Keep the final Gold table in place.
• Load changes through an incremental strategy such as MERGE, using a reliable unique_key.
• Use on_schema_change deliberately so that schema changes are handled rather than silently forcing destructive rebuilds.
• Run the semantic model refresh only after the dbt job has completed successfully.
• Reserve --full-refresh for controlled maintenance windows because it can recreate the relation and temporarily invalidate downstream consumers.

If you occasionally need to rebuild all rows, another option is a custom materialization that preserves the target table and replaces its contents through TRUNCATE/DELETE followed by INSERT, where that pattern is supported and appropriate. The important part is to avoid dropping the published table itself.

I would also separate the build layer from the serving layer where possible:

• dbt builds or validates data in staging objects.
• The final Gold table is updated in place.
• Data-quality checks complete.
• The Direct Lake semantic model is reframed.
• Reports are then allowed to consume the new version.

A staging-table rename or swap needs testing as well, because although the final name may remain the same, replacing the underlying relation can still change the object that the semantic model is bound to.

So I agree that incremental materialization is the right direction. I would regard it as part of the architecture for any dbt-managed table serving Direct Lake, rather than only as a temporary fix for the refresh error.