dbt Fusion cannot replace a Databricks materialized view with a table

Changing a dbt model from materialized_view to table looks like a config edit, but the existing Databricks object still controls the replacement path. An open dbt issue reports that Fusion v2 treats the existing materialized view as a managed table and attempts CREATE OR REPLACE TABLE, which fails with DELTA_NOT_A_DELTA_TABLE. The reporter says dbt v1 drops the materialized view first.

Reproduce against the exact object

Record dbt distribution and adapter versions, Unity Catalog location, the current relation type, and the new materialization. In a lower environment, run the model as a materialized view, change only its config, and inspect the generated DDL on rerun.

Plan the destructive step

A materialization switch can require dropping an existing relation. Confirm downstream dependencies, refresh windows, grants, and rollback before any manual DDL. Do not add an automatic DROP to a shared production job merely because the reported v2 behavior fails.

Make migration a gated change

Pin the working version or use an explicitly reviewed migration sequence until the upstream issue is resolved and verified in your adapter combination. Test both view and table transitions, then compare model output and permissions after recreation.

Adovo’s view

A model name is an interface; a relation type is part of its contract. Treat a materialization change as a schema migration, with dependency and rollback checks, even when the source file changes by one word.