dbt and the transformation layer: an architecture fit assessment

1. Executive summary

Adopt dbt. It is still the right answer, and for the first time in years the reason to think twice is not technical.

The technical news is good, and better than I expected. The Fusion engine is a full rewrite of dbt's core in Rust as a real SQL compiler — it parses up to 30× faster than dbt Core on large projects (the 10,000-model kind), validates SQL without a warehouse round-trip, and enables state-aware orchestration that skips work it can prove is unnecessary. That last one is not a speed feature, it is a cost feature, and on a big project it is the difference between a dev loop of seconds and one of coffee breaks. dbt Core v2.0 open-sources the runtime under Apache 2.0 — though v2.0 is still alpha, and I would not put an alpha on the critical path of a platform this year.

The non-technical news is the assessment. On 1 June 2026 Fivetran and dbt Labs completed an all-stock merger. Before it, Fivetran had acquired SQLMesh — the most credible open-source alternative to dbt — and subsequently donated SQLMesh to the Linux Foundation. Read that sequence twice. One company now controls dbt Core, the Fusion engine, dbt Cloud's pricing, and the leading open-source rival to all three. Nobody has done anything wrong, and the Linux Foundation donation is a genuinely meaningful governance commitment. But "there is a credible alternative if this goes badly" was load-bearing in every dbt recommendation I have made for six years, and it is now doing much less work than it used to.

2. Positioning

dbt's actual insight was never technical. It was that SQL transformations are software, and should therefore have version control, tests, code review, documentation, and CI — the things every other engineering discipline had settled decades earlier. Templated SQL was the delivery mechanism for that argument, not the point of it. This matters for the assessment because it explains why "dbt but faster" is not a competitor and why hand-rolled SQL scores so badly: the competition is not about generating SQL, it is about whether your transformation layer is engineered or merely written.

SQLMesh's differentiator is worth understanding rather than dismissing, because it is real engineering and not marketing. Because it parses SQL properly instead of templating strings, it can tell whether a change to a model is breaking or non-breaking, and therefore whether downstream tables need rebuilding at all. Its virtual data environments give each developer a view over shared physical tables instead of a full recompute per person. If you have ever watched a dbt developer wait forty minutes to rebuild a dev schema in order to change a CASE statement, you understand exactly what problem that solves. Fusion moves dbt toward the same place — a true SQL compiler is the prerequisite — and it is genuinely converging.

3. Radar criteria — the reasoning

Modeling expressiveness

SQLMesh 4.4 edges dbt 4.3 — both give you refs, macros, and modular SQL; SQLMesh's understanding of the SQL itself lets it do things dbt approximates. Warehouse-native 3.2: declarative and limited. Hand-rolled 2.6, which flatters it.

Build performance

dbt 4.4 — this is Fusion's headline and it is not marketing: up to 30× faster parsing on 10k-model projects, and state-aware orchestration that skips provably unnecessary work. SQLMesh 4.3, which had this property from the start. Warehouse-native 4.2, since the engine does the work. Hand-rolled 3.0.

Incremental correctness

The axis where dbt is genuinely behind: 3.6. dbt asks you to write the incremental strategy and then trusts you, which means every subtly-wrong is_incremental() block silently produces subtly-wrong data for months. SQLMesh 4.7 reasons about it from the parsed SQL. Warehouse-native 4.0. Hand-rolled 2.4. If your team has been burned by a bad backfill, this row is why you should look at SQLMesh — see my incremental-processing notes for how expensive the failure mode is.

Testing & data quality

dbt 4.2 and SQLMesh 4.4. dbt's tests are the reason the category exists at all — being able to say not_null and unique in YAML brought data testing to teams that were never going to write a test suite. SQLMesh adds audits and stronger typing. Warehouse-native 3.2: possible, unnatural. Hand-rolled 2.0.

Lineage & documentation

dbt 4.4 — docs and the DAG are generated from the code, so they cannot rot the way a wiki does. SQLMesh 4.4 with genuinely better column-level lineage. Warehouse-native 3.4, hand-rolled 1.8 — and 1.8 is generous, because undocumented SQL is worse than no SQL.

CI / dev loop

SQLMesh 4.6 for virtual environments — no full rebuild per developer is a structural advantage, not a tuning one. dbt 4.3, transformed by Fusion's ability to validate SQL without hitting the warehouse; the dev loop is the thing Fusion most improves and the thing users notice first. Warehouse-native 3.0: CI against a live warehouse is slow and expensive. Hand-rolled 2.4.

Governance

dbt 3.9 and SQLMesh 3.9. Both are the transformation layer, not the access-control layer — they inherit governance from the warehouse. Warehouse-native 4.2 wins here almost by definition, since it never leaves the governed boundary. Hand-rolled 2.2.

Ecosystem & hiring

dbt 4.9, and this is the axis that keeps the recommendation where it is. Every warehouse has an adapter, every BI tool integrates, every analytics engineer on the market has used it, and the packages you need already exist. SQLMesh 3.2: good engineering, small community — you will train every hire. Warehouse-native 3.4, hand-rolled 2.6.

Ops burden

Warehouse-native 4.5 — nothing to run. dbt 4.1: dbt Core is a CLI in CI, which is about as light as a real tool gets. SQLMesh 3.9. Hand-rolled 1.8, because "no tool" means you built a worse one by accident.

Vendor & licence risk

dbt 3.0 — the lowest score I give it on any axis, and the reason this assessment exists. The merged Fivetran/dbt Labs entity controls dbt Core, the Fusion roadmap, dbt Cloud's pricing, and SQLMesh. Maintaining three overlapping products indefinitely is not a thing companies do, so at some point that portfolio gets rationalised, and you do not get a vote. SQLMesh 3.2 — Linux Foundation governance is real protection, and it was donated by the company that owns the competitor, which is a fact worth holding in mind rather than a conspiracy. Warehouse-native 2.6 is the most locked-in option on the page and nobody frames it that way. Hand-rolled 4.6: the only thing it is good at is that nobody can take it away from you.

4. Radar scorecard

How these scores are arrived at — the rings, the 0–5 scale, and the evidence rules — is written up in the radar methodology. This table and the chart below are generated from one file, scorecards.json: the source of truth, machine-readable, and kept separate so two copies of the same numbers cannot drift apart between editions. Last reviewed 2026-Q3.

Comparator scores (same axis order) — SQLMesh: 4.4 / 4.3 / 4.7 / 4.4 / 4.4 / 4.6 / 3.9 / 3.2 / 3.9 / 3.2. Warehouse-native: 3.2 / 4.2 / 4 / 3.2 / 3.4 / 3 / 4.2 / 3.4 / 4.5 / 2.6. Hand-rolled SQL: 2.6 / 3 / 2.4 / 2 / 1.8 / 2.4 / 2.2 / 2.6 / 1.8 / 4.6.

5. The radar

Ten-axis fit for the SQL transformation layer. dbt and SQLMesh are nearly the same polygon with two informative differences: SQLMesh wins incremental correctness and the dev loop, dbt wins ecosystem by a mile. Hand-rolled SQL is on the chart to make a point — it is worst on nine axes and best on the tenth, which is exactly why people keep choosing it. Click any name in the legend to toggle it on or off — comparing two shapes at a time is far more legible than comparing four.

6. Workload-specific analysis

7. Reference architecture

The shape that keeps your options open: dbt Core runs in your CI against your warehouse, the orchestrator triggers it, and nothing Cloud-only sits on the critical path. That is not paranoia — it is the cheapest insurance available in this category, and it costs approximately one afternoon.

graph LR
  DEV["Analytics engineer"] --> GIT["Git
models + tests"]
  GIT --> CI["CI
dbt-core build"]
  CI -->|"validate, no warehouse"| FUS["Fusion
SQL compiler"]
  CI --> PR["PR review
+ slim CI"]
  PR --> ORC["Orchestrator
Dagster / Airflow"]
  ORC --> RUN["dbt build
prod target"]
  RAW[("Raw tables")] --> RUN
  RUN --> MART[("Curated marts")]
  RUN -.->|"test failure"| ALERT["Alerting"]
  RUN -.->|"manifest.json"| LIN["Lineage + docs"]
  MART --> SEM["Metrics layer"]
  SEM --> BI["BI / apps"]
  GOV["Warehouse RBAC"] -.->|"governs"| MART

The two lines that matter most in any dbt project, and the ones most often written wrong — the incremental strategy dbt trusts you to get right:

-- The axis where dbt scores 3.6: it will not check this for you.
{{ config(
    materialized='incremental',
    unique_key='order_id',
    -- 'merge' is the safe default. 'append' is faster and will silently
    -- duplicate rows the first time a late-arriving record shows up.
    incremental_strategy='merge',
    on_schema_change='fail'
) }}

select order_id, customer_id, updated_at, revenue
from {{ ref('stg_orders') }}

{% if is_incremental() %}
  -- The classic bug: >= max(updated_at) re-reads the boundary row,
  -- > max(updated_at) drops records that share the boundary timestamp.
  -- A lookback window is the honest fix for late-arriving data.
  where updated_at >= (
      select coalesce(max(updated_at), '1900-01-01') - interval '3 days'
      from {{ this }}
  )
{% endif %}

8. POC plan (4 weeks)

• Week 1 — measure your dev loop before you migrate anything. Time a full parse and a dev rebuild on your real project. If Fusion takes that from minutes to seconds, the SQLMesh case just got much weaker and you have saved yourself a migration. Most teams evaluating alternatives are actually complaining about a problem Fusion fixes.
• Week 2 — audit your incremental models. For each one, ask: what happens on a late-arriving record? On a schema change? On a backfill of a month you already loaded? This is the axis where dbt scores 3.6, and the answer tells you whether SQLMesh is solving a real problem for you or an imagined one.
• Week 3 — port ten models to SQLMesh. Not because you will switch, but because knowing what the alternative costs is the only thing that makes "we could switch" a true statement rather than a comforting one. Time it honestly and write the number down.
• Week 4 — decide, and write the portability rules. Re-score this table. Then write down explicitly which dbt Cloud features you will allow on the critical path — my answer is none — and put that in the ADR. That single paragraph is worth more than the rest of the POC.

9. Final recommendation

Adopt dbt. Stay on Core. Keep your models portable, and treat that as a standing rule rather than a phase.

dbt remains the right default and the Fusion engine makes it a better tool rather than just a newer one — a real Rust SQL compiler, roughly 30× faster parsing on large projects, validation without a warehouse round-trip, and state-aware orchestration that declines to rebuild what it can prove has not changed. Open-sourced in Core v2.0. On the axes that decide platform choices over years — ecosystem, hiring, the sheer number of people who already know it — nothing else is close, and that is not inertia, it is a genuine engineering asset.

Look seriously at SQLMesh in exactly one situation: incremental correctness is hurting you. If your team has shipped subtly wrong numbers because an is_incremental() block was subtly wrong, SQLMesh's ability to reason about breaking versus non-breaking changes from parsed SQL is not a nicer version of dbt — it is a different and better answer to your actual problem. Its virtual data environments are the other genuine advantage, and neither is marketing.

The thing I would put in the ADR, though, is the one that has nothing to do with either tool's engineering. One company now owns dbt Core, Fusion, dbt Cloud, and SQLMesh. That is not an accusation — the Linux Foundation donation of SQLMesh is a real and creditable governance commitment, and nobody has behaved badly. But an argument I have leaned on for six years, "there is a credible alternative if this goes wrong", is now substantially weaker, and pretending otherwise would be dishonest. The response is not to avoid dbt. It is to keep dbt-core running in your own CI, refuse to put Cloud-only features on the critical path, and preserve the portability while it is free. Re-assess when the merged entity publishes a roadmap that says what happens to SQLMesh — that is the single fact that would move this page.

References

The merger is recent enough that most commentary is speculation. I have separated what has been announced from what people think it means, because the difference matters here more than usual.

Scores are my own architect-level judgment for the stated use case, calibrated to mid-2026 — not a vendor ranking. Transformation-layer axes; NOT comparable with the analytics assessments. Re-score against your own POC numbers before you commit.