dbt-labs/dbt-core · error

only available with Databricks adapter

Error message

only available with Databricks adapter

What it means

compute_external_path builds the storage location path for Databricks external tables from location_root plus the model's database/schema/alias; it is a Databricks-only API (dbt-databricks impl.py#L307). On every other adapter the match falls through to unimplemented!() and panics.

Source

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

                        node.schema().trim_end_matches('/'),
                        node.alias()
                    )
                } else {
                    format!("{}/{}", location_root.trim_end_matches('/'), node.alias())
                };

                let path = if is_incremental {
                    format!("{path}_tmp")
                } else {
                    path
                };
                Ok(path)
            }

            Postgres | Snowflake | Bigquery | Redshift | Salesforce | Spark | DuckDB
            | LakeCompute | Fabric | ClickHouse | Exasol | Starburst | Athena | Trino
            | Datafusion | Dremio | Oracle => {
                unimplemented!("only available with Databricks adapter")
            }
        }
    }

    /// DatabricksAdapter https://github.com/databricks/dbt-databricks/blob/2f11abb306a400cde32b27891b766bf41a11fb1f/dbt/adapters/databricks/impl.py#L298
    pub fn update_tblproperties_for_uniform_iceberg(
        &self,
        state: &State,
        conn: &mut dyn Connection,
        config: ModelConfig,
        node: &InternalDbtNodeWrapper,
        tblproperties: &mut IndexMap<String, Value>,
        token: CancellationToken,
    ) -> AdapterResult<()> {
        match self.adapter_type() {
            adapter_type @ Databricks => {
                // TODO(anna): Ideally from_model_config_and_catalogs would just take in an InternalDbtNodeWrapper instead of a Value. This is blocked by a Snowflake hack in `snowflake__drop_table`.
                let node_yml = node.as_internal_node().serialize();

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Wrap the call in an adapter.type() == 'databricks' guard in the materialization macro
  2. Ensure models using external tables are only selected when targeting Databricks
  3. Set location_root in the Databricks warehouse config so the Databricks path (not the panic arm) is taken

Example fix

{% if adapter.type() == 'databricks' %}
  {% set path = adapter.compute_external_path(config, model, is_incremental) %}
{% else %}
  {# non-Databricks external path handling #}
{% endif %}
Defensive patterns

Strategy: type-guard

Validate before calling

{% if adapter.type() == 'databricks' and config.get('location_root') %}
  {# safe to call compute_external_path #}
{% endif %}

Type guard

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

Try / catch

// unimplemented! panics; gate the call on adapter type
if adapter.adapter_type() == AdapterType::Databricks {
    let path = adapter.compute_external_path(config, node, is_incremental)?;
}

Prevention

When it happens

Trigger: Calling adapter.compute_external_path(config, node, is_incremental) when the adapter is not Databricks — typically from an external-table materialization macro running against Snowflake, BigQuery, DuckDB, etc.

Common situations: External-table macros written for dbt-databricks are reused in a non-Databricks project; a model with location_root/external config is targeted at the wrong warehouse; multi-target projects where the Databricks macro set runs for all targets.

Related errors


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