← Back to all sparks
D

dbt Core

ANALYTICS
Velocity7.5

Analytics engineering framework for transforming data in the warehouse

Two engines in one repo: the Python 1.x line tightens while Fusion 2.0 goes lakehouse-catalog native

data-transformationlakehouseicebergdual-enginecatalogsbreaking-changes
Current state
dbt-core is releasing on two tracks at once. The Python line reached 1.12.0 on 16 July after three release candidates, and it is a tightening release: the experimental `dbt login` command and the bundled dbt-state plugin were removed outright, and flags introduced in 1.9 and 1.10 now default to true. The 2.0.0 alpha track is the Fusion engine, and its work is almost entirely about catalogs — read-write Horizon and Unity access over Iceberg REST via DuckDB, a catalogs.yml v2 covering DuckLake, Iceberg REST and local filesystem, plus catalog_database overrides and Redshift catalog generation through SHOW TABLES and SVV_REDSHIFT_COLUMNS.
Where it's heading
The division of labour between the two tracks is clear from the entries: 1.x is consolidating and removing experiments, while 2.0 is where the new surface area lands. The 2.0 surface is specifically the lakehouse catalog layer — dbt is moving from a tool that writes to a warehouse toward one that binds to open table catalogs directly, with materialization made catalog-aware. Notably 1.12.0rc1 also teaches the Python engine to tolerate Fusion-specific warn_error_options rather than erroring, so the two engines are being made to coexist in the same projects rather than fork.
Prediction
The alphas are still expanding catalog coverage adapter by adapter, so expect further catalog integrations and continued catalogs.yml v2 work before 2.0 leaves alpha. On the Python side, with the deprecated flags now defaulted and the experimental commands removed, 1.12 looks like a stabilization point rather than a base for new features.

Recent moves

  1. 12d ago

    Fusion alpha 5: Redshift datasharing catalogs and job-specific deferral

    The fifth 2.0 alpha continues the catalog theme: Redshift catalog macros move to SHOW TABLES and SVV_REDSHIFT_COLUMNS so generation works across shared databases, catalog_database support lands, and DBT_CLOUD_DEFER_JOB_ID enables job-specific deferral. Incremental filling-in of the Fusion track rather than a new direction.

    View source ↗
  2. 15d ago

    dbt-core 1.12.0 drops `dbt login` and the dbt-state plugin

    ⚡ SPARK

    The 1.12.0 stable release removes the experimental `dbt login` command and the bundled dbt-state plugin, including --manage-state and the DBT_ENGINE_STATE_* env vars, and flips the 1.9 and 1.10 flags to default true. It is the release where the Python line stops carrying experiments forward, which matters more than the features shipped alongside it.

    View source ↗
  3. 17d ago

    1.12.0 release candidate 3

    The third release candidate for 1.12.0, adding CLI usage hints and fixing dependency resolution so refs declared inside an overloaded UDF body are carried onto the root function node instead of being dropped from the DAG. Staging work for the stable release two days later.

    View source ↗
  4. 22d ago

    1.12.0 release candidate 2

    Release candidate 2 for 1.12.0, carrying the flag-default breaking change and adding catalog_database to CatalogWriteIntegrationConfig so catalogs.yml can override the database name for any catalog type. A staging cut of what ships as stable a week later.

    View source ↗
  5. 25d ago

    1.12.0 release candidate 1

    The first 1.12.0 candidate, where the removal of `dbt login` and dbt-state first appears. It also makes the Python engine tolerate Fusion-specific warn_error_options rather than erroring on them, which is the small signal that the two engines are meant to share project config.

    View source ↗
  6. 26d ago

    Fusion gains read-write Iceberg REST catalogs and catalogs.yml v2

    ⚡ SPARK

    Fusion's DuckDB path gains read-write access to Horizon and Unity catalogs through Iceberg REST, and catalogs.yml v2 adds DuckLake, Iceberg REST and local filesystem catalogs with catalog-aware materialization. This upgrades an earlier read-only integration into a write path, which is the difference between reading a lakehouse and building into one.

    View source ↗