dbt-labs/dbt-core · error

supports_create_or_replace is not implemented for {:?}

Error message

supports_create_or_replace is not implemented for {:?}

What it means

`CatalogRelation::supports_create_or_replace` is only implemented for the Databricks adapter type (true for Iceberg table format or Delta file format); any other `adapter_type` stored on the relation hits `unimplemented!` and panics. The method encodes a per-adapter capability question that simply has no answer coded for other warehouses yet. It is a code-completeness gap, not a reflection of whether your actual table supports CREATE OR REPLACE.

Source

Thrown at crates/dbt-adapter/src/catalog_relation.rs:1479

            base_location: None,
            adapter_properties: BTreeMap::new(),
            is_transient: Some(true),
            file_format: None,
        }
    }

    // === end HACK

    pub fn supports_create_or_replace(&self) -> bool {
        match self.adapter_type {
            AdapterType::Databricks => {
                self.table_format.is_iceberg()
                    || self
                        .file_format
                        .as_deref()
                        .is_some_and(|f| f.eq_ignore_ascii_case("delta"))
            }
            _ => unimplemented!(
                "supports_create_or_replace is not implemented for {:?}",
                self.adapter_type
            ),
        }
    }

    // helper for get_value in impl Object
    fn gate_by_adapter(
        &self,
        adapter_types: Vec<AdapterType>,
        value_fetch: impl Fn() -> Value,
    ) -> Value {
        if adapter_types.contains(&self.adapter_type) {
            value_fetch()
        } else {
            Value::from(())
        }
    }

View on GitHub (pinned to 0267ce9170)

Solutions

1. Only call supports_create_or_replace on Databricks catalog relations; for other adapters use their native create-or-replace semantics (most support it directly).
2. Extend the match in catalog_relation.rs to return the appropriate boolean for your adapter type instead of panicking.
3. Guard call sites with a check that the relation's adapter_type is Databricks and fall back to a default assumption otherwise.

Example fix

// before
let ok = relation.supports_create_or_replace();
// after
let ok = match relation.adapter_type {
    AdapterType::Databricks => relation.supports_create_or_replace(),
    _ => true, // most warehouses support create or replace natively
};

// Rust
fn create_or_replace_known(t: &AdapterType) -> bool {
    matches!(t, AdapterType::Databricks)
}

let supports = if relation.adapter_type == AdapterType::Databricks {
    relation.supports_create_or_replace()
} else { true };

// No catch possible; narrow before the call
match relation.adapter_type {
    AdapterType::Databricks => relation.supports_create_or_replace(),
    _ => true,
}

When it happens

Trigger: Calling `catalog_relation.supports_create_or_replace()` on a CatalogRelation whose `adapter_type` is anything other than Databricks — e.g. Snowflake or BigQuery relations built by macros that then probe create-or-replace support.

Common situations: Materialization macros that probe create-or-replace support across warehouses; building a CatalogRelation with a non-Databricks adapter_type and reusing Databricks-era helper code; tests constructing relations with default adapter types.

Related errors

• only available with Databricksadapter
• only available with Databricks adapter
• resolve_file_format is only supported in Databricks
• update_tblproperties_for_uniform_iceberg is only supported i
• is_uniform is only supported in Databricks

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/c332b64d22372241. Report an issue: GitHub.