Citus
Citus keeps three Postgres branches alive while chasing each new major
A side-by-side editorial comparison of dbt Core and Apache Iceberg — release velocity, themes, recent moves, and the top alternatives to consider.
Two engines in one repo: the Python 1.x line tightens while Fusion 2.0 goes lakehouse-catalog native
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.
Iceberg's release cadence is now backports and CVE patches across three live minor lines.
The project is maintaining 1.9.x, 1.10.x and 1.11.x concurrently, and the visible work is overwhelmingly maintenance: dependency bumps, backported fixes, and a steady stream of correctness repairs around nullability, deletes and the REST catalog. 1.10.2 in particular is almost entirely backports plus a CVE fix in a compression dependency.
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.
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.
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.
The project is maintaining 1.9.x, 1.10.x and 1.11.x concurrently, and the visible work is overwhelmingly maintenance: dependency bumps, backported fixes, and a steady stream of correctness repairs around nullability, deletes and the REST catalog. 1.10.2 in particular is almost entirely backports plus a CVE fix in a compression dependency.
The feature story lives in the minor releases and the spec, not the patches — Flink 2.0 support, Variant type work reaching Parquet readers, and repeated REST catalog validation fixes point at a format spending its effort on engine breadth and on the REST catalog as the standard access path. The patch stream shows a format mature enough that its hardest problems are now schema-evolution edge cases and cleanup-on-failure semantics.
Expect continued parallel maintenance of the 1.10.x and 1.11.x lines with backports dominating, and the next substantive work to land in Variant type coverage and REST catalog behaviour rather than in the core table spec.
Other Analytics products tracked by Sparkpulse, ranked by recent ship velocity. Each card links to a full editorial trajectory and lets you pivot into a head-to-head comparison with either dbt Core or Apache Iceberg.
Citus keeps three Postgres branches alive while chasing each new major
Three releases in a year, all of them about the Vega dependency — the feed shows nothing else.
Kylin ships once a year with empty release notes and a native engine nobody is being told about.
Feature releases every two months in 2024; one bugfix release in the last twelve.
MCP servers became first-class governed assets in 1.13.0 — and 2.0 is now in release candidate.
Every release in this window is columnstore work — compression is where TimescaleDB is spending
See all dbt Core alternatives → · See all Apache Iceberg alternatives →
Latest ship moves from both products, interleaved chronologically. ⚡ = editorial spark.
Both compete on the same themes — lakehouse — within Analytics. dbt Core is currently shipping more aggressively (velocity 7.5 vs 0.0), with 2 editorial sparks in the last 30 days against 0. See the at-a-glance table above for a side-by-side breakdown of velocity, recent sparks, and editorial themes.
Sparkpulse doesn't pick a winner — we score release velocity, not feature parity. dbt Core is currently shipping more aggressively (velocity 7.5 vs 0.0), with 2 editorial sparks in the last 30 days against 0. For your specific use case, the alternatives sections above list other Analytics products to evaluate alongside.
Top dbt Core alternatives in Analytics are ranked by recent ship velocity. Browse the "dbt Core alternatives" section above for the current picks, or visit /alternatives/dbt-core for the full list with editorial commentary on each.
Top Apache Iceberg alternatives in Analytics are ranked by recent ship velocity. Browse the "Apache Iceberg alternatives" section above for the current picks, or visit /alternatives/apache-iceberg for the full list with editorial commentary on each.