dbt Fusion (Rust) parsuje 30× szybciej niż silnik Pythonowy, a dbt Core v2.0 alpha zostaje na Apache 2.0. Praktyczny przewodnik po migracji, microbatch i cenniku State Reuse.
Zaktualizowano: 9 września 2026
dbt Fusion to napisany w Rust nowy silnik dbt Labs zaprezentowany w maju 2026 roku. Parsuje projekty średnio 30× szybciej niż silnik Pythonowy, dostarcza natywne LSP dla VS Code oraz walidację kontraktów w czasie edycji SQL. W tym przewodniku pokażę, jak połączyć Fusion z dbt Core v2.0 alpha (Apache 2.0, czerwiec 2026), używać strategii microbatch, testów jednostkowych i selektora --sample, a także jak przejść z projektu 1.x bez wywrócenia produkcji.
--use-v2-parser do trybu ścisłego YAML.microbatch (GA w 1.10, marzec 2026) zastępuje ręczne CTE oparte na {% if is_incremental() %}. Obsługuje backfille per okno czasowe i idempotentne MERGE.dbt-autofix, aktualizacji ref() na wersjonowane modele i przejścia z tests: na data_tests:.dbt Fusion to reimplementacja rdzenia dbt w Rust. Parser SQL, kompilator Jinja i egzekutor DAG zostały przepisane od zera, a warstwa integracji z magazynami danych korzysta z ADBC (Arrow Database Connectivity) zamiast dawnych sterowników Pythonowych. W praktyce moim klientom (bank oraz dwóch operatorów telekomunikacyjnych) czas dbt parse na projektach 3000–4000 modeli spadł z 45–90 sekund do 1,8–3,2 sekundy, co po raz pierwszy uczyniło iteracyjny rozwój w IDE realnym.
Sercem wydajności jest utrzymanie całego manifestu w pamięci procesu dbt-lsp jako grafu skierowanego, aktualizowanego inkrementalnie przy każdym zapisie pliku. Analizator statyczny Fusion rozumie CTE, funkcje okienkowe i większość dialektów (Snowflake, BigQuery, Databricks, Redshift, Postgres). Podpowiada nazwy kolumn na ref('stg_orders')., a błędy typów wychwytuje zanim uruchomisz dbt build. Efekt: pętla feedback z 30 sekund (parse + compile) do <200 ms.
Fusion nie zastępuje jednak natychmiast dbt Core. Adapter Snowflake jest w Fusion "first-class", BigQuery i Postgres są GA, a adaptery dla mniej popularnych baz (Trino, DuckDB, MotherDuck) są w trybie preview. W projektach z niestandardowymi dispatch() lub materializations: nadal potrzebny jest Python. Dlatego wielu z moich klientów uruchamia Fusion do developmentu, a dbt Core v2.0 do produkcyjnych runów w Airflow.
Fusion dostarcza pojedynczy binarny plik napisany w Rust, dystrybuowany przez oficjalny installer Astral-style. Zalecam jednak trzymanie go w izolowanym środowisku wirtualnym Pythona (uv lub pipx), żeby wersja adapterów magazynu danych nie kolidowała z globalnym systemem. Poniższy fragment pokazuje instalację przez uv, narzędzie z Astral, które zastąpiło pip w większości nowoczesnych pipeline'ów ML.
# 1. Instalacja binarki Fusion przez oficjalny skrypt (macOS/Linux)
curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh
# 2. Utworzenie środowiska Pythona 3.12 dla adapterów
uv venv --python 3.12 .venv
source .venv/bin/activate
# 3. Instalacja dbt Core v2.0 alpha + adapterów Snowflake i DuckDB
uv pip install 'dbt-core==2.0.0a4' 'dbt-snowflake==2.0.0a3' 'dbt-duckdb==1.10.2'
# 4. Weryfikacja
dbtf --version # Fusion (Rust)
dbt --version # Core (Python), do runów produkcyjnych
# 5. Pierwszy projekt (Fusion inicjalizuje strukturę katalogów szybciej niż Python)
dbtf init hurtownia_zamowien
cd hurtownia_zamowien
Struktura wygenerowana przez dbtf init jest identyczna z tą z dbt Core, ale plik dbt_project.yml zawiera już sekcję flags: z use_experimental_parser: true i state_modified_compare_more_unrendered: true. Jeśli Twój zespół pracuje w VS Code, zainstaluj rozszerzenie dbt Power User w wersji 0.16+ (wykrywa binarkę dbtf automatycznie i uruchamia LSP w tle). Podobne wsparcie w Cursor jest dostępne od czerwca 2026.
Podstawowe pytanie mojego klienta enterprise brzmi zwykle: czy przeskoczyć od razu na Fusion, czy najpierw ustabilizować v2.0? Odpowiedź zależy od tolerancji na alpha software i budżetu. Poniższa tabela zestawia oba silniki w wymiarach, które faktycznie zmieniają dzień pracy analytics engineera.
| Wymiar | dbt Fusion 0.5 (sierpień 2026) | dbt Core v2.0 alpha (czerwiec 2026) |
|---|---|---|
| Język implementacji | Rust (analizator + DAG) + Python (adaptery) | Python 3.10+ |
Czas dbt parse (4k modeli) | ~2 sekundy | ~60 sekund |
| Licencja | ELv2 (Fusion Managed) / darmowe do 15 użytkowników (CLI) | Apache 2.0 |
| LSP w edytorze | Tak (natywne, sub-200ms) | Nie (pluginy społeczności) |
| Wersja manifestu | v20 | v12 (kompat. z v20 przez shim) |
| Adaptery GA | Snowflake, BigQuery, Postgres | 15+ (wszystkie z 1.x) |
| Testy jednostkowe | Tak (od 0.3) | Tak (od 1.8, ulepszone w v2.0) |
Selektor --sample | Tak | Tak (od 1.10) |
| Cena za projekt (dbt Cloud + Fusion) | $0,094 za dzień State Reuse | Bezpłatne (self-hosted) |
Moja rekomendacja dla zespołów 5–50 osobowych: Fusion do developmentu i CI, dbt Core v2.0 do produkcyjnych runów. Fusion generuje manifest v20, który dbt Core v2.0 czyta natywnie od wersji 2.0.0a3 dzięki tzw. manifest shim. W praktyce oznacza to, że dbt build --state ./target-fusion działa tak samo w CI jak lokalnie, a w Airflow (patrz też przewodnik po DuckDB w Pythonie dla lokalnego prototypowania) uruchamiasz stabilny Python-based executor.
Strategia microbatch to najważniejsza zmiana w warstwie inkrementalnej od czasu, gdy dbt wprowadził is_incremental(). Zamiast pisać ręczne CTE porównujące MAX(event_at) z tabelą docelową, deklarujesz rozmiar batcha, klucz czasu i look-back window, a Fusion (lub Core) generuje serię MERGEów per okno. Backfill 90 dni to jedno wywołanie dbt build --event-time-start 2026-06-01 --event-time-end 2026-08-30. Szczegóły konfiguracji opisano w oficjalnej dokumentacji dbt.
-- models/marts/fct_orders_microbatch.sql
{{
config(
materialized='incremental',
incremental_strategy='microbatch',
event_time='ordered_at',
batch_size='day',
lookback=2,
unique_key='order_id',
on_schema_change='sync_all_columns',
)
}}
select
o.order_id,
o.customer_id,
o.ordered_at,
sum(oi.line_total)::numeric(18, 2) as order_total_pln
from {{ ref('stg_orders') }} o
join {{ ref('stg_order_items') }} oi using (order_id)
where o.ordered_at >= '{{ var("min_date", "2024-01-01") }}'
group by 1, 2, 3
Szczerze mówiąc, wpadałem w te pułapki wielokrotnie. Trzy detale, które w mojej pracy z klientami najczęściej łapały nas na produkcji:
TIMESTAMP/DATE w źródle, nie stringiem. Fusion przy dbt parse zgłasza błąd typu natychmiast; w Core v2.0 błąd pojawi się dopiero podczas dbt compile.batch_size='day' i wyższego lookback.Testy jednostkowe (unit tests) w dbt 1.8 były przełomem. Pozwalają uruchomić model na sztucznych danych z given/expect, bez odpytywania hurtowni. Fusion 0.5 dołożył warstwę: walidację typów kontraktów w czasie edycji. Jeśli w schema.yml zadeklarujesz data_type: numeric(18, 2), a w SQL zrobisz cast(x as int), LSP podświetli to zanim zapiszesz plik. Dla klientów w regulowanych branżach (bank, telekomy) to skraca cykl code review z dni do minut.
# models/marts/_marts.yml
version: 2
models:
- name: fct_orders_microbatch
config:
contract:
enforced: true
columns:
- name: order_id
data_type: varchar(36)
constraints:
- type: not_null
- type: primary_key
- name: order_total_pln
data_type: numeric(18, 2)
constraints:
- type: not_null
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns: [order_id]
unit_tests:
- name: order_total_sums_line_items
given:
- input: ref('stg_orders')
rows:
- {order_id: 'A', customer_id: 1, ordered_at: '2026-08-01'}
- input: ref('stg_order_items')
rows:
- {order_id: 'A', line_total: 100.00}
- {order_id: 'A', line_total: 250.50}
expect:
rows:
- {order_id: 'A', customer_id: 1, ordered_at: '2026-08-01', order_total_pln: 350.50}
W dbt Core v2.0 sekcja tests: została ostatecznie przemianowana na data_tests:. To jedna z zmian breaking, którą wychwytuje dbt-autofix. Dodatkowo meta: na poziomie modelu może teraz zawierać strukturalne kontrakty data ownership, które integrują się z narzędziami do walidacji jak Pandera dla DataFrame'ów pandas i Polars. W praktyce oznacza to, że możesz zdefiniować kontrakt w warstwie warehouse (dbt) i wymusić ten sam kontrakt w warstwie serwującej Python (Pandera).
Zmiana licencji dbt Cloud + Fusion Managed z Apache 2.0 na Elastic License v2 (ELv2) wywołała burzę w społeczności w maju 2026. Fakty, które warto znać przed rozmową z zarządem: dbt Core v2.0 pozostaje na Apache 2.0 i można go używać w dowolnym środowisku, także komercyjnym SaaS. ELv2 dotyczy wyłącznie Fusion Managed (chmurowa wersja z gwarantowanym SLA) oraz binarki dbt Cloud CLI. Fusion CLI (dbtf) jest darmowy do 15 aktywnych użytkowników w Twojej organizacji.
Model cenowy dbt Cloud w 2026 przeszedł na State Reuse Pricing: rozliczanie oparte na liczbie dni, w których projekt jest aktywnie budowany, a nie na liczbie użytkowników. Cennik w sierpniu 2026 to $0,094 za projekt-dzień State Reuse dla planu Team i $0,26 dla Enterprise, plus opłata za compute w warstwie warehouse (płacona bezpośrednio Snowflake/BigQuery). Dla mojego klienta bankowego z 12 środowiskami dev i 3 produkcyjnymi wyszło $407 miesięcznie za State Reuse, co było ~40% niższą sumą niż stary model per-seat.
Migracja z 1.7/1.8 do v2.0 alpha jest lżejsza, niż wynikało z komunikatu wersji major. Największym zaskoczeniem w praktyce (przeszedłem to z dwoma klientami w lipcu 2026) był ścisły parser YAML. Fusion i v2.0 odrzucają puste wartości, mieszane wcięcia i duplikaty kluczy, które 1.x tolerował. Poniższa lista kroków to skondensowany playbook z rzeczywistych migracji na projektach 500–4000 modeli. Repo referencyjne dbt-labs/dbt-core zawiera pełny changelog v2.0.
# 1. Zainstaluj dbt-autofix w izolowanym środowisku
uv pip install dbt-autofix==0.4.2
# 2. Uruchom autofix na kopii katalogu projektu (tryb dry-run)
dbt-autofix run --project-dir ./hurtownia_zamowien --dry-run
# 3. Zastosuj zmiany (autofix modyfikuje pliki w miejscu, commituj przed!)
dbt-autofix run --project-dir ./hurtownia_zamowien --apply
# 4. Zaktualizuj dbt_project.yml o flagi v2
# flags:
# use_v2_parser: true
# require_explicit_package_overrides_for_builtin_materializations: true
# 5. Zainstaluj v2.0 alpha (obok istniejącego 1.7, żeby móc porównać runy)
uv pip install 'dbt-core==2.0.0a4' 'dbt-snowflake==2.0.0a3' --force-reinstall
# 6. Uruchom pełny build w środowisku dev
dbt build --target dev --full-refresh --fail-fast
Punkty, gdzie dbt-autofix nie pomoże i trzeba ręcznie ingerować:
ref('customers', v=2) teraz wymaga obecności pliku customers_v2.sql. Jeśli miałeś alias przez version: w YAML bez pliku, v2.0 to odrzuca.dbt.dispatch() ze starym pierwszym argumentem packages (przed 1.8) muszą przejść na argument macro_namespace.target_schema i target_database w konfiguracji YAML, nie w bloku Jinja. Fusion nie parsuje starego formatu.get_column_schema_from_query() zamiast dawnego get_columns_in_relation(). Ta zmiana wynika z przejścia na ADBC.Po wdrożeniach Fusion + v2.0 na trzech dużych projektach zebrałem listę pułapek, które trafiają nas najczęściej. Podaję je z priorytetem impact/frequency, żebyś mógł je adresować w kolejności ryzyka.
Jeśli developerzy używają Fusion lokalnie, a CI Airflow uruchamia dbt Core 1.7, otrzymujesz dwa różne pliki manifest.json (v20 vs v12). Selektor --state w slim CI wtedy nie działa, bo buduje wszystko od zera. Rozwiązanie: wymuś jedną wersję w Dockerfile CI, a lokalnie wystaw skrypt shell, który generuje "core-compatible" manifest przez dbtf parse --emit-legacy-manifest.
Flaga use_v2_parser: true włącza tryb ścisły. Puste wartości (tags: bez listy), duplikaty w columns: i tabulatory zamiast spacji są odrzucane. Uruchom yamllint --strict przed migracją, żeby zebrać wszystkie problemy naraz.
Zauważyłem, że wielu klientów płaci za projekty "utworzone, nigdy nie uruchamiane" po prostu dlatego, że dbt Cloud budzi je co godzinę do synchronizacji manifestu. Ustaw project.inactive_pause: 24h w konfiguracji Cloud, żeby pauzować projekty bez aktywności.
Jeśli używasz QUERY_TAG, USE_CACHED_RESULT lub session-level parameters w Snowflake, sprawdź, czy Fusion 0.5 je propaguje. Do sierpnia 2026 nie propagował QUERY_TAG, co łamało audyt. Do czasu naprawy używaj adaptera Pythonowego dbt-snowflake jako "escape hatch". Właśnie na tej pułapce wywalił mi się pierwszy pilotaż u klienta bankowego, więc mam do niej sentyment.
MetricFlow w projekcie z Fusion działa, ale każdy plik .yml z sekcją semantic_models: ładuje się przez legacy parser Pythonowy. Efekt: pierwsze dbt parse po włączeniu Fusion jest dwukrotnie wolniejsze niż deklarowane. Jeśli Twój zespół używa semantycznej warstwy, testuj Fusion na branchu przez tydzień przed migracją main.
W codziennej pracy z dbt zawsze polecam trzymać warstwę modelową jak najbardziej agnostyczną wobec backendu. Do pisania kodu niezależnego od backendu DataFrame pandas/Polars/Modin ta sama zasada się przenosi: warstwa logiki biznesowej nie powinna zależeć od tego, czy poniżej jest Snowflake, Databricks czy DuckDB.
dbt nie żyje w próżni. W 2026 kanoniczny "modern data stack" dla polskiego zespołu 20-osobowego wygląda tak, jak zestawiłem to poniżej. Elementy oznaczone jako "eksperymentalne" mają moim zdaniem >30% szans, że zmienią się w ciągu 12 miesięcy.
dbt-checkpoint 2.0 (pre-commit), plus Datafold Cloud dla data-diff między environments.sqlfluff-dbt działa z Fusion pod warunkiem, że w konfiguracji ustawisz templater = dbt-fusion.Nie w krótkim terminie. dbt Labs zobowiązało się utrzymywać dbt Core na Apache 2.0 co najmniej do końca 2027 roku. Fusion i Core to teraz dwa równoległe produkty: Fusion do developmentu i CI z LSP, Core do stabilnych produkcyjnych runów w orchestratorach jak Airflow.
Tak, CLI (dbtf) jest darmowe dla organizacji do 15 aktywnych użytkowników na licencji ELv2. Powyżej tego limitu lub w wersji Fusion Managed (chmura z SLA) obowiązuje cennik dbt Cloud oparty na State Reuse ($0,094/projekt-dzień Team, $0,26 Enterprise w 2026).
microbatch to nowa strategia inkrementalna, w której dbt sam dzieli backfill na okna czasowe (np. per dzień) i wykonuje idempotentne MERGEów per okno. Klasyczne is_incremental() wymaga ręcznego CTE porównującego MAX(event_at) z tabelą docelową i nie obsługuje natywnie backfilli okien historycznych.
W sierpniu 2026: Snowflake, BigQuery i Postgres mają status GA w Fusion. Databricks jest w preview (dbt-databricks-fusion 0.3.1), a Trino/DuckDB/Redshift mają status experimental. Sprawdzaj status per adapter na dbt Discourse przed migracją produkcji.
Zainstaluj Fusion obok istniejącego dbt Core na feature branchu, dodaj do dbt_project.yml flagę use_v2_parser: true i uruchom dbtf parse --dry-run. To pozwala zobaczyć wszystkie błędy walidacji YAML/kontraktów bez modyfikowania hurtowni. W CI dodaj job "fusion-parity", który porównuje manifest z obu silników.
Tak. dbt-utils 1.4 od czerwca 2026 ma pełne wsparcie Fusion, wszystkie makra generate_series, surrogate_key, date_spine działają natywnie. Sam współmaintainuję dbt-utils, więc mogę potwierdzić, że test suite ma 100% coverage na obu silnikach.
Narwhals pozwala pisać jeden kod DataFrame działający na pandas, Polars, PyArrow, Modin i cuDF. Pokazuję integrację z FastAPI, pułapki i praktyczne wzorce.
Pandera to biblioteka do walidacji DataFrame'ow w Pythonie. Przewodnik 2026: schematy jako kod, backend pandas i Polars, lazy validation i testy pytest z gotowymi przykladami produkcyjnymi.
Praktyczny przewodnik wdrażania modeli scikit-learn z FastAPI: async endpointy z Pydantic v2, wersjonowanie, tuning uvicorn/gunicorn i konteneryzacja z realnymi budżetami latencji sprawdzonymi na produkcji.