dbt Fusion adds a v2 catalogs.yml override for physical database/catalog naming
This gives teams a single, adapter-agnostic override point to pin which physical database/catalog a model lands in, independent of per-model config or the target's database — useful for multi-catalog Unity/BigLake setups where the logical model config shouldn't dictate physical placement. It also signals dbt is standardizing catalog-relation resolution across adapters rather than special-casing each one.
What changed
dbt's Fusion engine (v2.0.0-alpha.5) adds `catalog_database` support to v2 catalogs.yml: when set, it takes highest priority over model-level database config and target.database when generating the database name for a relation. It reuses the existing build_catalog_relation pattern with no new adapter method, and is supported on Snowflake (all catalog types), BigQuery (biglake_metastore), and Databricks (unity, falling back to catalog_name if unset).
Why it matters
This gives teams a single, adapter-agnostic override point to pin which physical database/catalog a model lands in, independent of per-model config or the target's database — useful for multi-catalog Unity/BigLake setups where the logical model config shouldn't dictate physical placement. It also signals dbt is standardizing catalog-relation resolution across adapters rather than special-casing each one.