dbt-labs/dbt-core · error

only available with Databricksadapter

Error message

only available with Databricksadapter

What it means

compare_dbr_version compares the current Databricks Runtime version against a given major/minor and returns -1/0/1; it exists only on the Databricks adapter (dbt-databricks impl.py#L349). Any other adapter type hits the unimplemented!() arm and panics, since DBR versioning is a Databricks-only concept.

Source

Thrown at crates/dbt-adapter/src/adapter/adapter_impl.rs:4185

                let query_ctx =
                    query_ctx_from_state(state)?.with_desc("compare_dbr_version adapter call");

                let current_version =
                    DatabricksMetadataAdapter::get_engine_version(self, &query_ctx, conn, token)?;
                let expected_version = EngineVersion::Full(major, minor);

                let result = match current_version.cmp(&expected_version) {
                    std::cmp::Ordering::Greater => 1,
                    std::cmp::Ordering::Equal => 0,
                    std::cmp::Ordering::Less => -1,
                };

                Ok(Value::from(result))
            }
            Postgres | Snowflake | Bigquery | Redshift | Salesforce | Spark | DuckDB
            | LakeCompute | Fabric | ClickHouse | Exasol | Starburst | Athena | Trino
            | Datafusion | Dremio | Oracle => {
                unimplemented!("only available with Databricksadapter")
            }
        }
    }

    /// Get the external root directory from engine config, defaulting to `"."`.
    pub fn external_root(&self) -> String {
        self.engine()
            .config("external_root")
            .unwrap_or(Cow::Borrowed("."))
            .into_owned()
    }

    /// Build the write-options string for DuckDB external materializations.
    pub fn external_write_options(&self, write_location: &str, rendered_options: &Value) -> String {
        let mut opts: IndexMap<String, String> = IndexMap::new();
        if let Ok(keys) = rendered_options.try_iter() {
            for key in keys {
                let key_str = key.to_string();

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Guard with `{% if adapter.type() == 'databricks' %}` before any compare_dbr_version call
  2. Fix the target/profile so the Databricks adapter is selected when running Databricks materializations
  3. For other platforms, remove DBR-version-dependent logic or replace with platform-appropriate checks

Example fix

{% if adapter.type() == 'databricks' %}
  {% set cmp = adapter.compare_dbr_version(14, 3) %}
{% endif %}
Defensive patterns

Strategy: type-guard

Validate before calling

{% if adapter.type() == 'databricks' %}
  {% set cmp = adapter.compare_dbr_version(14, 3) %}
{% endif %}

Type guard

fn is_databricks(adapter: &AdapterImpl) -> bool { adapter.adapter_type() == AdapterType::Databricks }

Try / catch

// Panic-based unimplemented!; guard before invoking
if adapter.adapter_type() == AdapterType::Databricks {
    let cmp = adapter.compare_dbr_version(state, conn, major, minor, token)?;
}

Prevention

When it happens

Trigger: Calling adapter.compare_dbr_version(state, conn, major, minor, token) while adapter_type() is Postgres, Snowflake, Bigquery, Redshift, Spark, DuckDB, or any other non-Databricks adapter. Note this is typically invoked from Databricks materialization macros (e.g. uniform/iceberg checks).

Common situations: A Databricks-specific macro from dbt-databricks runs in a project whose active target is another warehouse; a shared macro bundle executes DBR capability checks unconditionally; the model's selected profile points at the wrong adapter.

Related errors


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