[v2 Bug] --full-refresh on materialized_view breaks Databricks Compatibility Mode (LOCATION_OVERLAP)

Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

• I believe this is a new bug in dbt v2.x
• I have searched the existing issues and could not find a duplicate

Current Behavior

When running dbt run --full-refresh (or dbt build --full-refresh) on a model materialized as materialized_view with delta.universalFormat.enabledFormats = 'compatibility' set via tblproperties, the run fails with:

[error] [DbDriverFailed (dbt1308)]: Database Error in model <model_name> failed to execute query: databricks: execution error: failed to execute query: unexpected operation state ERROR_STATE: [RequestId=... ErrorClass=INVALID_PARAMETER_VALUE.LOCATION_OVERLAP] Input path url 's3://.../' overlaps with other external tables or volumes within '' call. Conflicting tables/volumes: ..<model_name>.

This happens even on a completely fresh, never-before-used S3 location — the very first --full-refresh on a brand-new materialized view with this config already fails.

Root cause: for --full-refresh on materialized views, dbt issues two separate statements: DROP MATERIALIZED VIEW IF EXISTS catalog.schema.model_name; CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.model_name (...) TBLPROPERTIES (...) AS SELECT ...

Databricks' Compatibility Mode (public preview UniForm feature, see https://docs.databricks.com/aws/en/external-access/compatibility-mode) does not release its location-exclusivity lock synchronously when the table is dropped. The immediate CREATE that follows is therefore rejected as conflicting with "another table" at the same location — even though it's the same model being recreated.

I confirmed via manual SQL in the Databricks SQL editor that running the exact same CREATE OR REPLACE MATERIALIZED VIEW ... TBLPROPERTIES(delta.universalFormat.compatibility.location = ...) statement twice in a row, with no DROP in between, succeeds both times without any error.

This shows the DROP step is unnecessary — CREATE OR REPLACE is already sufficient to fully replace the object, compatibility-mode location included — and its presence is the direct cause of the failure.

Expected Behavior

--full-refresh on a materialized_view should not require, or should not immediately follow, a DROP MATERIALIZED VIEW with CREATE OR REPLACE MATERIALIZED VIEW at the same location. Ideally the adapter would use CREATE OR REPLACE MATERIALIZED VIEW alone for full-refresh (mirroring how the table materialization full-refreshes via a single atomic CREATE OR REPLACE TABLE ... AS SELECT, without a preceding DROP), or add a delay/retry around the drop+create when Compatibility Mode tblproperties are detected.

Steps To Reproduce

1. Ensure your Databricks workspace/warehouse supports Unity Catalog + serverless SQL Warehouses.
2. Create a model with: {{ config( materialized='materialized_view', tblproperties={ 'delta.universalFormat.enabledFormats': 'compatibility', 'delta.universalFormat.compatibility.location': 's3:///' } ) }} select * from {{ ref('some_upstream_model') }}
3. Run dbt run --select this_model — succeeds, creates the MV.
4. Run dbt run --select this_model --full-refresh — fails with INVALID_PARAMETER_VALUE.LOCATION_OVERLAP. Note: a plain dbt run (no --full-refresh) on subsequent invocations succeeds fine, since it only issues REFRESH MATERIALIZED VIEW rather than DROP + CREATE.

Relevant log output

$ dbt run --select my_materialized_view --full-refresh --debug
/* {"app": "dbt", "dbt_version": "2.0.0", "invocation_id": "<uuid>", "node_id": "model.my_project.my_materialized_view", "profile_name": "my_profile", "target_name": "my_target"} */
drop materialized view if exists `my_catalog`.`my_schema`.`my_materialized_view`
/* {"app": "dbt", "dbt_version": "2.0.0", "invocation_id": "<uuid>", "node_id": "model.my_project.my_materialized_view", "profile_name": "my_profile", "target_name": "my_target"} */
create or replace materialized view `my_catalog`.`my_schema`.`my_materialized_view`
  (
        `id` bigint,
        `event_date` date,
        `name` STRING,
        `description` STRING
  )
    tblproperties ('delta.universalFormat.enabledFormats' = 'compatibility' , 'delta.universalFormat.compatibility.location' = 's3://<bucket>/<never-used-path>'
    )
  as
    select
    *
from `my_catalog`.`my_schema`.`my_upstream_table`
Finished running [ 23.42s] model my_materialized_view [error]
    Failed model my_materialized_view (mat_view) [1 of 1 in 23.42s]
=================== Errors and Warnings ====================
[error] [DbDriverFailed (dbt1308)]: Database Error in model my_materialized_view (target/run/my_project/models/my_materialized_view.sql)
  failed to execute query: databricks: execution error: failed to execute query: unexpected operation state ERROR_STATE: [RequestId=<request-id> ErrorClass=INVALID_PARAMETER_VALUE.LOCATION_OVERLAP] Input path url 's3://<bucket>/<never-used-path>' overlaps with other external tables or volumes within '' call. Conflicting tables/volumes: my_catalog.my_schema.my_materialized_view.
  (in run/my_project/models/my_materialized_view.sql)
==================== Execution Summary =====================
Finished 'run' with 1 error for target 'my_target' [24.8s]
Processed: 1 model
Summary: 1 total | 1 error
Note: this run used a brand-new, never-before-used S3 location — the immediately preceding plain
`dbt run` (no --full-refresh) on this exact same fresh path had succeeded cleanly, so this isn't a
stale-state artifact; it's the very first --full-refresh attempt failing on a virgin location.

Environment

- OS: macOS 26.2 (arm64)
- CPU: ARM (Apple Silicon)
- dbt distribution and version: dbt 2.0.4 (Fusion)

Which database adapter are you using?

databricks

Is this a discrepancy vs. dbt 1.x?

• Yes — this works in dbt 1.x but not in dbt v2.x

Additional Context

Is this a discrepancy vs. dbt 1.x? Unconfirmed — likely also present in dbt-databricks 1.x since the underlying materialized_view full-refresh logic (drop then create) appears conceptually the same. Filing a companion issue in databricks/dbt-databricks to confirm.

Databricks Compatibility Mode docs: https://docs.databricks.com/aws/en/external-access/compatibility-mode Relevant constraint from the docs: "The target location and any parent or child folders must not have been used as a Compatibility Mode location for another table within the last 7 days." — this appears to be the mechanism triggering the failure, since Databricks treats the freshly-dropped-and-recreated table as "another table" at that location. Workaround: setting full_refresh=false in the model config (https://docs.getdbt.com/reference/resource-configs/full_refresh) excludes the model from --full-refresh entirely, avoiding the DROP+CREATE path. Not ideal since it means this model can never be full-refreshed via dbt without manual intervention (drop, wait for Databricks to release the compat-mode lock, then dbt run). Companion issue filed against databricks/dbt-databricks: https://github.com/databricks/dbt-databricks/issues/1683