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
- Wrap the call in an adapter.type() == 'databricks' guard in the materialization macro
- Ensure models using external tables are only selected when targeting Databricks
- 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
- Only enable external-table materializations for Databricks targets
- Require location_root in Databricks warehouse config so the Databricks path is used
- Audit shared macros for unconditional external-path calls
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
- only available with Databricksadapter
- resolve_file_format is only supported in Databricks
- update_tblproperties_for_uniform_iceberg is only supported i
- is_uniform is only supported in Databricks
- supports_create_or_replace is not implemented for {:?}
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/fbae3e4eaf911367.
Report an issue: GitHub.