Fusion, Migration, Anti-Patterns & Staff-Level Judgement

Getting these four names wrong costs real money in two directions. Teams migrate to "the open-source Rust engine" and discover the binary they installed is proprietary and the Apache-licensed runtime is an alpha with no beta and no RC behind it. Other teams refuse to look at Fusion because "it is closed", and give up a static-analysis capability that catches a class of defect — an unresolvable column — that dbt Core 1.x structurally cannot see, since it templates SQL rather than comprehending it. The second cost is quieter: on dbt Core 1.x there is no column-level lineage at all, which Chapter 11 established, so every impact question is answered by reading models rather than by asking the tool.

The engine renders your Jinja to DDL exactly as before, so your custom materialization keeps working. What you lose is static analysis on that node: the engine cannot know whether your materialization changes columns, so it silently skips analysis for it. No error, no warning. You migrate, you believe you have column-level lineage, and on that subtree you quietly do not. Pre-flight every custom materialization before the migration, because nothing in the migration will mention them.

On Snowflake, BigQuery and Databricks, Python models are functional on the v2 engine. They sit outside the static-analysis story for the reason Chapter 21 spent a chapter on: dbt never reads your Python, so a Python model cannot be analysed as SQL. dbt Labs describe that as the last open question before GA. No source says Python models need static_analysis turned off, so this chapter does not say it either.

The dbt-fusion repository was retired in favour of dbt-core and its issues moved. It is not archived — GitHub reports archived: false — and its status is not evidence about the engine’s future in either direction. Chapter 21 made the same correction about dbt-redshift’s move into the adapters monorepo. A repository’s housekeeping is not a product decision.

The weak answer names two things and gets the licence wrong. The strong answer names four and separates the axes: dbt Core v1.x is the Python implementation under Apache 2.0; dbt Core v2.0 is the Rust runtime, also Apache 2.0, currently an alpha; the Fusion engine is a free binary built on that runtime plus proprietary code, under its own licence; and dbt platform is the commercial SaaS, renamed from dbt Cloud in May 2025. Then land the part that shows you have actually used it: status is per adapter and per surface, Snowflake is GA and Postgres is not supported at all.

The single fact that most changes how this comparison should be argued is an org fact, not a feature fact. Fivetran acquired Tobiko Data — SQLMesh and SQLGlot — on 2025-09-03, contributed SQLMesh (the open-source framework, not Tobiko Cloud) to the Linux Foundation on 2026-03-25, and completed its merger with dbt Labs on 2026-06-01. So since June 2026 the two tools most often framed as rivals share a corporate parent, and one of them sits under neutral foundation governance. Walking into an architecture review with "which one wins" is now a question about a company that owns both.

GitHub stars are printed because they have a single verifiable source and a read date: 13,575 against 3,233 on 2026-08-04, roughly 4.2×. Everything else people quote about these two tools — throughput multiples, cost savings, hiring-pool sizes — has either a vendor behind it or nothing behind it. This chapter prints no performance or cost number for either tool, on purpose, and says so out loud so the omission reads as a decision rather than an oversight.

The weak answer is a feature list in one direction. The strong answer starts with the org fact — Fivetran acquired Tobiko Data in September 2025, contributed SQLMesh to the Linux Foundation in March 2026, and completed the dbt Labs merger in June 2026, so both tools now share a parent. Then name two things SQLMesh genuinely does better with attribution: virtual data environments as a pointer swap, and automatic breaking / non-breaking change categorisation, which dbt has no equivalent for. Then give the honest reason a team stays: the migration is not free, and SQLMesh’s own documentation says dbt’s recommended incremental logic is not compatible. Refusing to quote a benchmark, and saying why, is the part interviewers remember.

All deprecation warnings become hard errors on v2, which turns everything you have been "meaning to get to" into a gate. The single most expensive line in the upgrade guide is about behaviour flags: they are removed, and verbatim, "You can no longer opt out of them using flags: in your dbt_project.yml." Every flag you set to defer work is now that work, due. Meanwhile three of the nine findings in a realistic preflight come from a human reading the repository rather than from any command — including the one nothing reports at all, because a custom materialization causes the engine to silently skip static analysis without erroring or warning. Any readiness estimate produced only by tooling is missing exactly the findings that carry schedule risk.

The prepare-fusion-upgrade guide (updated 2026-07-31) gives a real order: enable readiness, then move to the Latest release track in order — personal override, development, staging (run for several days to validate), production (monitor the first few runs), then jobs — then branch, run autofix, fix the residue by hand, open a PR, validate and upgrade packages, and finish with per-job eligibility triage. Mirror that order. But state the caveat honestly whenever you cite it: it is written for dbt platform customers and assumes an account and a developer licence. There is no equivalent published sequence for a pure dbt Core shop running its own CI, which is most readers of this chapter.

A custom materialization keeps working on v2 — the engine renders your Jinja to DDL as before. What it cannot do is know whether your materialization changes columns, so it silently skips static analysis for that node. It does not error and it does not warn. The failure mode is believing you migrated: green build, no findings, and a subtree with no column-level lineage and degraded DAG precision. Pre-flight custom materializations by hand, because nothing else will.

Do not recite the changelog. Give the shape: all deprecation warnings become hard errors, behaviour flags are removed so previously deferred work comes due, three parse-time strictness rules fail whole projects that used to parse, and a handful of CLI flags now silently do nothing rather than erroring. Then give the sentence that shows you have sized one: at 900 models the cost is not the engine, it is the long tail — this is a code-cleanup project wearing an engine-upgrade costume, and it should be budgeted as one.

An anti-pattern catalogue is only useful to somebody who has already felt the failure — which is why this arrives at chapter 22 rather than chapter 2. But four of the nine are NOT backed by dbt Labs guidance, and a catalogue that presents all nine with the same authority is teaching dogma. Three are backed strongly, two partially, and four are this knowledge base's engineering judgement, labelled as such in the backing callout below. The distinction matters in a real review: "dbt Labs' guide says staging is the only place the source macro appears" ends an argument; "I think this macro is too complex" starts one, and should.

Backed strongly: no staging layer (dbt Labs’ own guide — staging models are the only place the source macro is used, and joins are almost always a bad idea there); 800-line models (the marts guide on models spanning more than four or five concepts, plus the workflows guide’s three break-up triggers); incremental everywhere (the view → table → incremental ladder, verbatim). Partially backed: tests-only-on-PKs — dbt Labs’ baseline IS the primary-key test, and they have no published position that PK-only is insufficient, so the floor is cited and "coverage theatre" is owned as this knowledge base’s judgement; folder sprawl — the marts guide backs not over-optimising early, under ten marts, but also endorses grouping by department, so the objection is scoped to folders matching neither a source nor a real business area and carrying no config or ownership meaning. NOT backed, and owned as engineering judgement: snapshot-the-source (the historic "snapshot query best practices" block is no longer on the current docs page, and every quote of it is secondary); select * chains (dbt’s own style guide prescribes select * from final, so the objection must be scoped to a star on a ref() or source()); and macro complexity (dbt’s entire Jinja style guide is four cosmetic rules — there is no macro-complexity guidance to cite).

Chapter 7’s coverage map starts where most real projects start: 8 of 11 models carried a uniqueness badge and three carried nothing at all. The point here is not to re-run it — it is the inversion. Three defects in this knowledge base have a row-count delta of exactly zero: ep_1008 at 1,980 ms, where unique, not-null and accepted-values all pass and the value is 1,000× wrong; pct_completed reading 93,434.3 where the truth is 93.4; and Chapter 12’s fan-out at 1,000 rows in, 1,000 rows out and 11.63% wrong. A row-count reconcile is not evidence, and a checklist item that says "check the row count" contradicts three chapters at once.

dbt-project-evaluator v1.3.4 ships 29 rules across modeling, testing, documentation, structure, performance and governance, including fct_source_fanout, fct_direct_join_to_source and fct_missing_primary_key_tests. dbt-checkpoint provides community pre-commit hooks for the same territory. Two honest limits: printed thresholds are package defaults and configurable — chained_views_threshold is 5, or 4 on Athena, Trino and ClickHouse; models_fanout_threshold is 3 — and its require-dbt-version bound of [">=1.10.6", "<3.0.0"] admits v2 without dbt Labs certifying it on Fusion.

A list of nine anti-patterns is a memorised answer and interviewers can hear it. The strong answer names the shape instead: I split the review into what a machine can check and what only a person can. The machine checks snapshot ancestry, source fan-out, stars on refs, ownership metadata and incremental config — all off a parsed manifest, offline. What I read for is intent: does this change what one row means, what is the invariant that should hold before and after, did anyone see the new test fail, and is there anything in the blast radius that cannot be rebuilt. Then close with the asymmetry: I try just as hard not to flag lines that are fine, because a reviewer who flags everything teaches their team to ignore all of it.

The two breakages are symmetric and only one of them is loud. On the quiet side, a column arrives in a mart nobody selected it into: change content_rating to a PII column and the same mechanism is a compliance incident rather than an untidy dashboard. On the loud side, a dropped column breaks a model at run time, in production, with a warehouse error rather than a dbt one — and under a star chain it breaks three layers away from the change, in a mart, after two models have already built successfully. Under explicit projection the same drop fails in stg_episodes, the one model whose job is to know what this source looks like, with nothing downstream even attempted.

Chapter 11 owns the impact question and demonstrated it on listener_timezone. That traversal is cited here rather than repeated, and this section uses a fresh column — a content rating — so the two demonstrations do not collide. When you need to answer "who reads this column", go there; when you need to stop a column arriving in the first place, stay here.

Under the star chain, stg_episodes and int_episode_catalogue both build successfully carrying a shape nothing downstream can use, and the failure surfaces in the mart, at run time, in production. Two layers of green build in front of a red one is worse than a red one at the boundary, because it looks like the mart is broken when the source is.

Answer with the distinction rather than a position. select * from final as the last line of a model is prescribed by dbt’s own style guide: one final CTE projecting a column list assembled explicitly above it. A star directly on a ref() or a source(), propagating between models, is a different thing entirely — it is the absence of an interface, and it produces two symmetric failures: a new upstream column arriving in a dashboard nobody approved, and a dropped column breaking downstream at run time with a warehouse error. Then give the structural fix rather than the disciplinary one: an enforced contract fails on extra columns too, so the addition becomes loud at build time.

The design principle is the staff-level content here, and it is a claim rather than a platitude: anything a machine can check must not appear on the human checklist at all. An item a machine could verify, that a human is asked to verify, gets ticked without being read — and its presence teaches the reviewer that the whole list is theatre. That is why this checklist is six mechanical items the reviewer never sees, plus nine questions no linter can ask. The asymmetry in the widget is the other half: precision is not a bonus on top of recall. A reviewer who flags the sanctioned select * from final alongside the real star on a ref() has taught their author that the rule is arbitrary, and the next real finding gets discounted.

Intended grain. Whether a number is published anywhere a human actually looks. Whether the backfill is affordable tonight. Whether the blast radius contains something unrebuildable. Whether the owner is reachable at 2am. Whether the model’s name still tells the truth about what one row means. Whether a "domain" folder has a real second team behind it. Whether a macro’s compiled output is predictable before you look at it. That list is the entire justification for a human review existing at all — and every item a machine could have checked that you put next to it dilutes the eight that matter.

Take the three marts with the most downstream exposures and ask three different people who owns each. If you get three answers, the ownership metadata is decorative regardless of what the manifest says. No tool can run this check, it takes about four minutes, and it has a higher hit rate than anything in the CI script above.

The answer that lands is a design principle rather than a list: anything a machine can check must not appear on the human checklist at all, because an item a human is asked to verify that a machine could have verified gets ticked without being read — and its presence teaches the reviewer that the whole list is theatre. Then name the three things that turn a list into an artifact people keep: a waiver column, so "N/A because ___" is recorded rather than falsely ticked; a stated ordering rule, so people know which items block; and an anti-gaming line, because all nine ticked in under a minute is a process finding, not a code finding.

The metric substitution carries the whole section: measure LEGACY SCRIPTS RETIRED, not models built. "Models built" rewards duplication and is fully satisfied by a project that has doubled the number of places a number is computed — Chapter 12 put it plainly, the naive split is eight problems with better names. Retirement is the only metric on the list that can be satisfied solely by finishing. And the correct ordering is not correct because it feels incremental; it is correct because it is the only one that produces a falsifiable acceptance gate on day one: is there a mart in production dbt that a human actually uses?

Rounded to quarters of the quarter, not the widget’s own day-by-day count — the planner below lands the eight moves at 1–15, 16–32, 33–57 and 70–82 depending on the order chosen; read the bands here as approximate phases, not exact boundaries. Days ~1–15: one vertical slice, dbt build green in development, audit_helper clean against a FROZEN legacy relation. Measure: is there one mart in production dbt that a human uses — binary, not a count. Days ~15–32: CI on every pull request, a scheduled production run, source freshness on every source. Measure: wall clock from opening a PR to a green build, and the date of the first freshness WARN plus whether anybody acted on it. Days ~33–60: migrate by consumer, not by table, and retire a legacy script only after N agreed green comparison days. Days ~60–90: a grain test on every mart, a group and owner on every model, an exposure for every consumer. The plan and every one of these metrics is this knowledge base’s, not dbt Labs’ — say so when you present it.

On a plain run, a source freshness WARN does not fail the build — which is why the useful day-15 metric is the date of the first WARN and whether a human acted on it, not an exit code. With --warn-error a freshness WARN does exit 1, but dbt-core #12812 is open, so you gain the gate and lose the report. Chapter 5 has the full argument for when to gate a freshness WARN at all.

Do not list workstreams. Give the ordering and the reason it is the ordering: one vertical slice end to end — source, staging, one mart a real dashboard already reads — with tests, CI and a scheduled production run, because it is the only sequence that produces a falsifiable acceptance gate on day one. Then name what you would measure and why: legacy scripts retired, not models built, because models built rewards duplication and retirement is the only metric that can only be satisfied by finishing. Then name what you would explicitly exclude in the first quarter — mesh, contracts everywhere, the semantic layer, an engine migration — and say why each has a precondition you have not met. Naming the exclusions is what separates somebody who has led one from somebody who has read about one.

Everything in this knowledge base was building toward one capability, and it is not writing models. It is being the person in the room who can say what one row means, what would have to be true for this number to be wrong, who finds out if it is, and whether anything in the blast radius cannot be rebuilt. The tooling underneath that capability will keep moving — four of the eight claims in section 2 expired inside a year — and none of the movement changes the questions. Fusion, v2, SQLMesh and whatever follows are all answers to "how fast can the engine tell me". Nothing on the horizon answers "what should this number be", and that is the part somebody has to own.

A knowledge base that ships a project with no known defects is teaching a fiction. This one carries five, each with an owner and a decision: a uniqueness test on the wrong grain (should key on payment_id), an unfired rather than absent fan-out on ep_1005, a staging model with zero consumers that is nonetheless correct, naming drift on agg_daily_listens to be fixed when it is next touched rather than by a mass rename, and a source with freshness: null set deliberately. The last one is the most useful, because it produces the honest version of a checklist item most teams get wrong: every source needs a DELIBERATE freshness decision, and null is a legitimate one when it is written down.

Three of this chapter’s "wrong tool entirely" rows point somewhere specific. Orchestration — retries, sensors, SLAs, backfills — belongs to the Airflow knowledge base, and dbt Chapter 15 only covered how dbt is invoked from one. Whether the feature or the dimension is modelled correctly in the first place belongs to Data Modeling. And the ELT-versus-ETL decision, CDC capture and schema-evolution mechanics belong to Data Pipeline. dbt is one letter of three, and the judgement in this chapter is mostly about knowing which letter you are holding.

"What would you change about how your last team used dbt?" The weak answer is a tooling complaint. The strong answer picks one anti-pattern, names the detection signal that would have caught it, names what it cost by year two, and — this is the part almost nobody does — names the case where it would actually have been the right call. Then close on the review point: we could check six things mechanically and were checking them by hand, so nobody read them; and we were not asking the nine questions no tool can ask. Moving items from the human list to CI is not process work. It is the only way the human list survives contact with a busy week.