dbt Fusion en dbt Core v2 in Python 2026: Rust-engine, statische SQL-checks en tests die niet onderhandelbaar zijn

Bijgewerkt: 16 september 2026

dbt Fusion is de nieuwe Rust-gebaseerde uitvoeringsengine van dbt Labs die je bestaande dbt-project 20 tot 30 keer sneller parseert dan dbt Core 1.9 en tegelijkertijd statische SQL-typecontrole toevoegt voordat een query het datawarehouse raakt. In Python 2026 gebruik je Fusion als drop-in vervanging via uv tool install dbt-fusion of naast dbt-core voor een geleidelijke migratie richting dbt Core v2.0 (GA gepland voor december 2026). Deze gids laat zien hoe je overstapt zonder je pipeline-tests af te breken.

• dbt Fusion 0.5 (augustus 2026) draait op een Rust-engine met een parse-snelheid die 20-30x hoger ligt dan dbt Core 1.9, en levert statische SQL-typecontrole vóór de query het warehouse raakt.
• De nieuwe manifest v20 bevat kolom-niveau lineage, nullability en constraints; oudere tooling die manifest v12 leest, blijft werken via een shim.
• De microbatch incremental strategy is nu de aanbevolen manier om grote event-tabellen te verwerken met batch_size, lookback en event_time.
• dbt Core v2.0 (alpha juli 2026, GA december 2026) verhuist naar ELv2-licensing; de meeste projecten kunnen ongewijzigd blijven draaien op Core 1.9 en Fusion parallel.
• Fusion adapters voor Snowflake, BigQuery, Databricks, Postgres en Redshift zijn GA; DuckDB, Trino en Athena zitten in bèta.
• Unit tests met dbt test draaien in-memory via de Fusion-engine, ideaal voor CI-pipelines waar je geen warehouse-krediet wilt verbranden.

Wat is dbt Fusion en waarom moet je erop letten?

dbt Fusion is een compleet herschreven uitvoeringsengine voor dbt, in Rust, die dbt Labs in februari 2026 open source heeft gemaakt onder Apache 2.0. Waar dbt Core 1.9 nog Python gebruikt om Jinja te renderen, DAG's te bouwen en manifests te serialiseren, doet Fusion dit alles in native binaries. Het gevolg is een parse-fase die op een middelgroot project (~500 modellen) van dertig seconden naar ongeveer één seconde gaat. Dat klinkt als een leuke benchmark, maar in de praktijk is het het verschil tussen elke IDE-actie voelen als een build, of nauwelijks merken dat dbt draait.

Wat mij persoonlijk als data engineer nog belangrijker maakt: Fusion heeft een echte SQL-parser die het schema van je warehouse begrijpt. Vóór een dbt run weet Fusion al of je SELECT user_id::text op een bigint-kolom schrijft, of je een JOIN doet op incompatibele types, of je een kolom aanroept die niet bestaat. Ik heb decennia aan 3-uur-'s-nachts pages over foutgegane pipelines gezien die achteraf simpele typefouten bleken; Fusion vangt dat op voordat de CI zelfs maar naar het warehouse belt.

Fusion vervangt niet dbt Core direct. Je kunt beide naast elkaar installeren en model voor model migreren. dbt Cloud draait al standaard op Fusion sinds juli 2026, maar zelf-gehoste teams krijgen de keuze.

Installatie in Python: uv, pip en compatibiliteit

De aanbevolen manier om Fusion te installeren in 2026 is via uv, omdat de Rust-binary via een dunne Python-wrapper wordt geleverd en uv die veel sneller resolveert dan pip. Als je nog nooit met uv hebt gewerkt, kijk dan eerst bij onze gids over snelle lokale data-analyse met DuckDB. Daar staat een korte introductie tot moderne Python-tooling voor data teams.

# installeer Fusion als losstaande CLI (aanbevolen)
uv tool install dbt-fusion

# of naast dbt-core in dezelfde omgeving
uv add dbt-fusion dbt-core dbt-postgres

# controleer versie en engine
dbt --version
# dbt Fusion 0.5.3 (rust-engine 2026.08.14)
# dbt Core 1.9.4 (fallback available)

De officiële compatibiliteitstabel vermeldt welke adapters GA zijn op Fusion. Op moment van schrijven (september 2026): Snowflake, BigQuery, Databricks, Postgres en Redshift zijn GA; DuckDB, Trino en Athena zijn bèta; Materialize en Firebolt zitten nog in preview. Voor adapters die nog niet GA zijn, valt Fusion automatisch terug op de Python-engine, waarna je een waarschuwing in de logs krijgt.

Manifest v20: kolom-niveau lineage en type-inferentie

Een van de minder besproken maar praktisch grootste verbeteringen zit in het manifestformaat. dbt Core 1.9 gebruikt manifest v12; Fusion schrijft manifest v20. Het nieuwe formaat bevat voor elk model een volledige beschrijving per kolom: naam, geïnfereerd type, nullability, constraints en (nog belangrijker) verwijzingen naar de kolommen upstream waaruit dit veld is afgeleid. Dat is kolom-niveau lineage zonder dat je een aparte tool zoals SQLGlot hoeft toe te voegen.

import json
from pathlib import Path

manifest = json.loads(Path("target/manifest.json").read_text())
print(f"manifest versie: {manifest['metadata']['dbt_schema_version']}")

model = manifest["nodes"]["model.jaffle_shop.orders"]
for col_name, col in model["columns"].items():
    upstream = col.get("depends_on", {}).get("columns", [])
    nullable = col.get("constraints", {}).get("not_null", False)
    print(f"{col_name}: type={col['data_type']}, "
          f"nullable={not nullable}, upstream={upstream}")

Voor tools die nog manifest v12 verwachten (denk aan oudere versies van dbt-metabase, elementary of internen dashboards die je zelf hebt geschreven) levert Fusion een backward-compatibele shim: dbt compile --manifest-version 12. Bewaar dat als tijdelijke escape hatch, niet als eindtoestand. De shim laat de nieuwe velden namelijk vallen en dat is precies waarom je Fusion überhaupt draait.

Statische SQL-typecontrole in de praktijk

De statische typecontrole van Fusion draait als onderdeel van dbt parse. Fusion haalt eenmalig het schema van je warehouse op (of leest een gecachete versie in .dbt/schema_cache.json) en checkt vervolgens elk SELECT-statement. Ik draai dit in een pre-commit hook en het is de meest waardevolle verandering van 2026 voor mijn team.

# voorbeeld: bug die Fusion vangt vóór CI
# models/staging/stg_orders.sql
select
    order_id,
    customer_id::text as customer_id,
    -- customer_id is bigint upstream; cast naar text breekt een downstream JOIN
    amount / 100 as amount_usd
from {{ source('raw', 'orders') }}

$ dbt parse --engine fusion
[error] models/staging/stg_orders.sql:3:5
  type mismatch: customer_id declared as text but downstream model
  model.jaffle_shop.dim_customers expects bigint (from stg_customers.customer_id)
  hint: remove ::text or update dim_customers join condition

Dit soort fouten kwam vroeger pas boven tijdens dbt test, en bij intermittente data soms pas in productie. Fusion vangt ze in seconden. Je kunt de gevoeligheid tunen via dbt_project.yml:

# dbt_project.yml
flags:
  fusion:
    type_checking: strict          # strict | warn | off
    check_unused_columns: true     # waarschuw bij ongebruikte model-kolommen
    max_query_complexity: 500      # rijen in query-plan; blokkeer runaway CTEs

Zet type_checking in nieuwe projecten meteen op strict. In een bestaand project begin je met warn en werk je de output weg voordat je de sleutel omdraait. Reken op ongeveer een uur per honderd modellen als de codebase enigszins gedisciplineerd was.

Microbatch incremental: de nieuwe standaard voor grote tabellen

De microbatch incremental strategy verving in 2026 stilletjes insert_overwrite als de aanbevolen strategie voor event-tabellen groter dan een paar honderd miljoen rijen. In plaats van één query die alle nieuwe data verwerkt, splitst Fusion het werk in tijd-vensters op basis van event_time en draait elk venster als een aparte transactie. Dat betekent: kleinere transacties, herstartbare backfills en drastisch minder kans op runaway kosten.

-- models/marts/fct_orders.sql
{{ config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='ordered_at',
    batch_size='day',
    lookback=2,
    begin='2024-01-01'
) }}

select
    order_id,
    customer_id,
    ordered_at,
    amount_usd
from {{ ref('stg_orders') }}
{% if is_incremental() %}
  where ordered_at >= '{{ model.config.begin }}'
{% endif %}

batch_size kan hour, day, month of year zijn. lookback=2 betekent dat elke run de laatste twee vensters opnieuw draait, wat cruciaal is als upstream data late-arriving is (denk aan events die pas 24 uur later binnenkomen). Een backfill draai je met een simpel commando: dbt run --event-time-start 2024-06-01 --event-time-end 2024-07-01. Fusion draait de vensters parallel als je warehouse dat aankan.

Unit tests: waarom pipeline-tests niet onderhandelbaar zijn

Dit is het onderdeel waar ik het meest gepassioneerd over word, dus draag met me mee. In dbt 1.8 werden unit_tests geïntroduceerd; in Fusion draaien ze volledig in-memory zonder ooit het warehouse te raken. Dat betekent dat je testsuite van tien minuten naar tien seconden gaat en je in CI honderden edge cases kunt draaien zonder een cent aan compute uit te geven. Er is geen excuus meer om je transformaties ongetest te deployen.

# models/marts/_fct_orders.yml
unit_tests:
  - name: test_orders_amount_conversion
    model: fct_orders
    given:
      - input: ref('stg_orders')
        rows:
          - {order_id: 1, customer_id: 100, ordered_at: '2026-01-01', amount_cents: 12500}
          - {order_id: 2, customer_id: 100, ordered_at: '2026-01-01', amount_cents: 0}
          - {order_id: 3, customer_id: 200, ordered_at: '2026-01-01', amount_cents: null}
    expect:
      rows:
        - {order_id: 1, customer_id: 100, amount_usd: 125.00}
        - {order_id: 2, customer_id: 100, amount_usd: 0.00}
        # order_id 3 wordt uitgefilterd: amount_cents is null

$ dbt test --select fct_orders --engine fusion
1 of 1 START unit_test fct_orders::test_orders_amount_conversion .. [RUN]
1 of 1 PASS test_orders_amount_conversion .............. [PASS in 0.04s]

Done. PASS=1 WARN=0 ERROR=0 SKIP=0 TOTAL=1

Als de data quality voor jouw team belangrijk is, combineer dbt test gerust met een generieke framework als Great Expectations of Pandera voor validatie ná de load. Voor bredere achtergrond op data cleaning en validatie in Python, zie onze complete gids voor data opschonen met pandas 3.0. Maar begin met unit_tests: ze bewaken de SQL-logica zelf, niet alleen de datawaardes.

dbt Fusion vs SQLMesh vs SDF vergeleken

Fusion is niet het enige moderne SQL-transformatiekader in 2026. SQLMesh (Tobiko Data) en SDF (nu onderdeel van dbt Labs sinds de overname begin 2026) worden vaak in dezelfde adem genoemd. Hier is een eerlijke vergelijking op de dimensies die er echt toe doen als je een tool kiest voor de komende jaren:

Kenmerk	dbt Fusion 0.5	SQLMesh 0.55	SDF 0.20 (via dbt)
Engine	Rust	Python	Rust (gefuseerd in Fusion)
Statische SQL-typecheck	Ja (native)	Nee	Ja (nu in Fusion)
Virtuele omgevingen	Nee	Ja (blue/green)	Nee
Kolom-niveau lineage	Ja (manifest v20)	Ja	Ja
Unit tests	Ja (in-memory)	Ja (in-memory)	Ja
Adapter-dekking	5 GA + 3 bèta	10+ GA	Beperkt
Ecosysteem/community	Zeer groot (dbt)	Middelgroot, groeiend	Onderdeel dbt geworden
Licentie	Apache 2.0	Apache 2.0	Apache 2.0

Praktisch advies: als je al op dbt zit, is Fusion een no-brainer — je krijgt Rust-snelheid en SDF's typechecks in één stap zonder je project te herschrijven. SQLMesh is interessant als je hard leunt op virtuele omgevingen (blue/green deploys van hele modellen), maar dat is voor de meeste teams overkill. SDF los kopen heeft geen zin meer nu de features in Fusion zitten.

Migratiepad: van dbt Core 1.9 naar Fusion en Core v2.0

De veiligste migratie is een drietrapsraket. Sla geen stappen over, ook al lijkt het bij een klein project onnodig — de tussenstappen leveren precies de logs waarmee je later een breaking change kunt debuggen.

1. Stap 1 (week 1): draai Fusion in warn-modus naast Core 1.9. Voeg dbt parse --engine fusion --warn-only toe aan CI en verzamel een lijst van waarschuwingen. Repareer type-inconsistenties en verwijder onnodige execute-macro's.
2. Stap 2 (week 2-3): schakel type_checking: warn in productie in en promoveer Fusion tot de primaire engine voor lokale ontwikkeling en pre-commit hooks. Blijf productie-runs op Core 1.9 draaien totdat je een week draait zonder waarschuwingen.
3. Stap 3 (week 4+): promoveer Fusion tot productie-engine, zet type_checking: strict aan en plan de upgrade naar dbt Core v2.0 (GA gepland december 2026, ELv2-licentie). Voor gehoste dbt Cloud gebeurt v2.0 automatisch; voor zelf-gehoste projecten volgt een migratiescript.

CI/CD met dbt Fusion in GitHub Actions

Een pipeline is pas van jou als hij in CI groen wordt. Hieronder de configuratie die ik in productie draai voor Python-teams die Fusion inzetten. Let op het gebruik van --defer --state: alleen de gewijzigde modellen draaien, de rest komt van de laatste productie-manifest. Dat scheelt op een groot project makkelijk 90% van de compute.

# .github/workflows/dbt-ci.yml
name: dbt CI

on:
  pull_request:
    paths: ['dbt_project/**']

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v5
      - uses: astral-sh/setup-uv@v5
        with:
          version: '0.12.7'

      - name: install dbt Fusion
        run: uv tool install dbt-fusion==0.5.3

      - name: download production manifest
        run: |
          aws s3 cp s3://dbt-artifacts/prod/manifest.json ./prod-artifacts/

      - name: parse and typecheck
        working-directory: dbt_project
        run: dbt parse --engine fusion --warn-only

      - name: run only changed models
        working-directory: dbt_project
        run: |
          dbt build \
            --defer --state ./prod-artifacts \
            --select state:modified+ \
            --engine fusion

      - name: run unit tests
        working-directory: dbt_project
        run: dbt test --select test_type:unit --engine fusion

De state:modified+ selector pakt gewijzigde modellen én alles downstream ervan. dbt build combineert run en test: als een test faalt, worden downstream modellen automatisch overgeslagen. Voor grotere projecten voeg je --vars '{"is_ci": true}' toe zodat modellen die dat lezen een gesampelde variant kunnen draaien (bijvoorbeeld where sampled in een macro).

Productievalkuilen die ik zelf tegenkwam

Geen enkele engine is zonder scherpe randen. Dit zijn de vier valkuilen waar ik en collega's op zijn gestruikeld sinds we in Q2 2026 op Fusion overstapten. Modellen die je vandaag deployt, moeten hier morgen niet aan sneuvelen.

1. Manifest-shim vergeten in downstream tools. Elementary v2 leest nog manifest v12; als je Fusion draait zonder --manifest-version 12, gaat je data-observability plot leeglopen. Los op: shim aanzetten of upgrade naar Elementary v3.
2. Jinja-macro's die op parse-tijd query's uitvoeren. In Core 1.9 kon je met {% if execute %} een SELECT tegen het warehouse zetten binnen een macro. Fusion staat dit toe maar sequentialiseert het, waardoor parse-tijd omhoog schiet. Herschrijf zulke macro's naar on-run-start hooks of naar een dbt run-operation die je expliciet aanroept.
3. Timezone bij microbatch. event_time moet timezone-aware zijn. Als je upstream data timezone-naive is (kolom is timestamp in plaats van timestamptz), krijg je stille off-by-one op de vensterranden. Cast expliciet naar UTC in de staging-laag.
4. Adapter-fallback zonder logging. Als je een niet-GA adapter draait, valt Fusion terug op de Python-engine. In CI zie je dat aan een WARNING; in dbt Cloud staat het pas in de deep-logs. Zet fail_on_adapter_fallback: true in dbt_project.yml om per ongeluk terugvallen te blokkeren.

Voor teams die na een succesvolle migratie ook hun ML-serving in Python willen moderniseren, verwijs ik graag naar onze vergelijking van LitServe, BentoML en FastAPI voor productie model serving. Betrouwbare data-pipelines zijn het fundament; goede model-serving legt de rest.

Veelgestelde vragen

Is dbt Fusion open source?

Ja. dbt Fusion is sinds februari 2026 open source onder de Apache 2.0-licentie. De code staat op GitHub bij dbt-labs/dbt-fusion. Dat verandert niet met de release van dbt Core v2.0 (die naar ELv2 gaat).

Moet ik overstappen van dbt Core 1.9 naar dbt Fusion?

Als je project meer dan honderd modellen heeft, ja. De statische typecontrole en 20-30x snellere parse-tijd verdienen zich binnen weken terug. Voor kleine projecten (<30 modellen) is Fusion nog steeds nuttig, maar minder urgent. Volg het drietrapsmigratiepad hierboven om risico laag te houden.

Werkt dbt Fusion met DuckDB?

Ja, maar de DuckDB-adapter zit in september 2026 nog in bèta. Voor lokale ontwikkeling werkt het prima; voor productie zou ik nog een cyclus wachten of contingency-plannen inbouwen. De GA-status wordt verwacht in Q4 2026.

Wat is het verschil tussen dbt Fusion en SDF?

SDF was een losse SQL-transformation-tool met een Rust-engine en statische typechecks. Nadat dbt Labs SDF eind 2025 overnam, zijn de kernfeatures van SDF in dbt Fusion opgenomen. In 2026 gebruik je Fusion; SDF als losstaand product wordt niet meer actief ontwikkeld.

Kan ik dbt Fusion combineren met dbt Cloud?

Ja. dbt Cloud draait sinds juli 2026 standaard op Fusion, dus je krijgt de snelheids- en typecheck-verbeteringen automatisch. Voor zelf-gehoste teams die dbt Cloud gebruiken voor scheduling maar Fusion lokaal draaien, is de configuratie identiek, want Fusion respecteert dezelfde profiles.yml en dbt_project.yml.

Hoe test ik of Fusion mijn bestaande dbt-project ondersteunt?

Draai dbt parse --engine fusion --warn-only in een branch. Alle incompatibiliteiten verschijnen als waarschuwingen zonder je build te breken. Los ze op, schakel dan type_checking: warn in en verwerk de output binnen een sprint. Daarna zet je strict aan en ben je klaar.