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
- Guard with `{% if adapter.type() == 'databricks' %}` before any compare_dbr_version call
- Fix the target/profile so the Databricks adapter is selected when running Databricks materializations
- 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
- Wrap Databricks-only version checks in adapter.type() guards
- Exclude Databricks macros from non-Databricks materialization search paths
- Verify the active dbt target in CI pipelines before running
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
- 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
- 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/8b47a8322a4b73f9.
Report an issue: GitHub.