Softwareprofil

dbt: Editionen, Kosten und Datenmodelle richtig prüfen

Redaktion: Axel Schweizer · Profil aus Herstellerangaben · kein eigener Praxistest

ETL und Datentransformation · dbt · Quellenstand: 10.10.2026 · Redaktion: Axel Schweizer

dbt hilft Teams, bereits zugängliche Daten mit versionierten Modellen für Analysen aufzubereiten. Seit September 2026 bezeichnet der Name mehrere Distributionen und eine gesonderte Plattform. Für die Auswahl zählen Edition, Adapter, Korrekturen, Löschungen und Betriebskosten. Diese Einordnung stützt sich auf Herstellerunterlagen; wir haben dbt nicht selbst ausgeführt.

Profil auf einen Blick

Preis und Abrechnung: Lokale Distributionen kostenlos; Plattform Starter 100 USD je Nutzer/Monat, Umfang und Abrechnung bestätigen
Kostenlos nutzbar: dbt Core v1/dbt OSS v2/dbt v2 lokal; Plattform Developer: 1 Nutzer / 1 Projekt / 3.000 Modell-Builds monatlich
Hosting und Region: Lokal selbst bestimmen; Enterprise-Plattform mit wählbaren EU-Regionen. dbtState derzeit nur US-GCP
Sprache und Support: Englische Dokumentation; deutschsprachige Oberfläche und Support nicht bestätigt
Datenanbindung: Warehouse-/Datenplattform-Adapter; kein vollständiger Extraktions- und Ladeprozess. Version und Adapter gesondert prüfen
Wichtige Grenze: Corev1, OSSv2, volle v2-Distribution und Plattform haben unterschiedliche Lizenzen/Funktionen. Upsert ist keine automatische Löschübernahme
Vor der Auswahl prüfen: Adapterversion, Delete-/Backfill-Strategie, Freshness, Snapshots und konkrete Plattformkosten im Pilot belegen.

Herstellerangaben geprüft am 10.10.2026. Kein eigener Praxistest. Primärquelle beim Anbieter. Nicht bestätigte Angaben sind ausdrücklich gekennzeichnet.

dbt am eigenen Datenfall abnehmen

Die kostenlose Prüfvorlage mit 14 Kriterien stellt drei Wege gegenüber: dbt Core v1, dbt OSS v2 und dbt v2 mit dbt platform. Sie enthält einen synthetischen Fall mit Korrektur, Löschung, Replay und Schemawechsel. Sämtliche Kandidatenbewertungen sind offen und müssen in der gewählten Version und Umgebung belegt werden.

dbt-Prüfvorlage als JSON herunterladen Im Anforderungskatalog ausfüllen

Im Katalog „JSON-Projekt laden“ wählen und die ausgefüllte Fassung wieder als JSON sichern. Du darfst diese Vorlage kostenlos intern im Unternehmen verwenden, anpassen und mit dem Projektteam teilen; diese Erlaubnis geht der allgemeinen Download-Beschränkung im Impressum vor.

Welche Rolle dbt im Datenstack übernimmt

dbt verbindet sich über einen Adapter mit einer Datenbank, einem Warehouse oder einer Query Engine. Aus SQL-Modellen baut es dort Views oder Tabellen in Abhängigkeitsreihenfolge. Modelle, Tests und Dokumentation liegen als Projektdateien vor und lassen sich über Git prüfen. Rechenzeit, Speicherung und Rechte der angebundenen Datenplattform gehören zur Entscheidung. dbt: Einführung, Plattformen.

dbt ist vor allem das T eines ELT-Ablaufs. Daten aus Shop, ERP oder APIs müssen bereits passend bereitstehen; der Datenbankadapter lädt sie nicht aus jedem Fremdsystem. Ein erfolgreicher Modelllauf beweist weder einen vollständigen Import noch fachlich richtige Zahlen. Vorgelagerte Ladewege: ETL-Tools.

Welche dbt-Edition und welche Lizenz gemeint ist

Die Bezeichnungen änderten sich mit v2. „Core gegen Fusion“ ohne Version führt in die Irre. Laut Lizenz-FAQ und Herstellererklärung gilt:

Produktnamen und Lizenzstand am 10.10.2026
Weg	Technik und Lizenz	Was bei der Auswahl zählt
dbt Core v1.x	Python, Apache 2.0	Bestehende Projekte und v1-Adapter gesondert betrachten; Version und Supportstand festhalten.
dbt OSS v2	Rust, Apache 2.0; früher als „Core v2“ angekündigt	Offene Distribution für eigene Ausführung; weniger lokale Entwicklungsfunktionen als die volle v2-Distribution.
dbt v2	Rust, Apache-2.0-Kern plus proprietäre Komponenten unter dbt Product Licensing Agreement; früher „Fusion engine“	Lokal kostenlos nutzbar, auch ohne Plattformkonto; Lizenzbedingungen bei Einbettung in einen eigenen Dienst prüfen.
dbt platform	Gehosteter, proprietärer Dienst für v1 oder v2	IDE, Zeitplanung, CI, Monitoring und weitere Funktionen nach Tarif.

Der frühere ELv2-Hinweis beschreibt nicht die heutige v2-Lizenz. Ehemaliger ELv2-Code liegt nun unter Apache 2.0 im dbt-Repository; der volle Binary unterliegt der Produktlizenz. Für vollständig offene Software dbt OSS v2 oder Core v1 prüfen. Mehr dazu: Open-Source-BI-Tools.

Plattform, Adapter und Regionsgrenzen prüfen

Die dbt platform bündelt IDE, geplante Jobs, CI, Dokumentation und Warnungen. Lokal betriebenes dbt braucht dafür eigene Werkzeuge. Für v2 nennt die Adapterübersicht Snowflake, BigQuery, Databricks, Redshift und DuckDB als allgemein verfügbar; DuckDB nur für die CLI. Spark ist CLI-Beta, ClickHouse private Beta. Der Reifegrad kann lokal und in der Plattform abweichen. Ein v1-Adapter belegt keine v2-Parität; DuckDB v2 hat dokumentierte Lücken zum v1-Adapter. Funktionen und Version konkret prüfen.

Enterprise-Konten können laut Regionsdokumentation etwa Frankfurt, London oder Irland wählen; ein Konto erhält eine Region. dbt State ist derzeit nur in einer US-GCP-Region ausgewiesen. Enterprise+ nennt PrivateLink, IP-Beschränkungen und Hybrid Projects. Die Plattform sendet SQL ans Warehouse; Ergebnisse können während einer Sitzung im Anwendungsspeicher liegen. Datenschutzprüfung muss deshalb den gesamten Datenweg erfassen. Architektur.

Inkrementell bauen: Korrekturen, Hard Deletes und Schema

Ein View speichert das Ergebnis nicht zusätzlich und zeigt beim Abruf aktuelle Quelldaten; komplexe Views können teuer werden. Ein Table-Modell wird beim dbt-Lauf neu aufgebaut. Ein inkrementelles Modell baut zunächst eine Tabelle und verarbeitet danach nur die per SQL-Filter ausgewählten Zeilen. --full-refresh baut es vollständig neu. Materialisierungen, inkrementelle Modelle.

Bei merge kann unique_key eintreffende Zeilen bestehenden Zeilen zuordnen. Der Schlüssel allein entdeckt aber keine Zeile, die in der Quelle verschwunden ist. Ein Hard Delete benötigt ein erkennbares Löschsignal und entsprechende Merge-Logik, eine separate Löschanweisung oder einen begründeten vollständigen Neuaufbau. Selbst die Strategie delete+insert bedeutet nicht, dass alle in der Quelle fehlenden Schlüssel entfernt werden; ihr Verhalten richtet sich nach den für diesen Lauf ausgewählten Zeilen. insert_overwrite arbeitet dagegen auf Partitionen und verwendet unique_key nicht. Verspätete Änderungen brauchen ein ausreichend breites Zeitfenster oder einen gezielten Replay. dbt: CDC und Löschungen.

Bei Schemawechseln steuert on_schema_change das Modellverhalten, berechnet aber alte Zeilen nicht automatisch nach. Neue Spalten können dort bis zum Backfill oder Full Refresh leer bleiben.

Tests, Freshness und Snapshots richtig einordnen

dbt liefert vier generische Datentests: not_null, unique, accepted_values und relationships. Eigene Tests können fachliche Betragsregeln prüfen. Sie müssen im Job laufen; ein Test korrigiert Daten nicht selbst. dbt: Datentests.

Freshness vergleicht einen gemessenen Datenstand mit konfigurierten Warn- und Fehlerschwellen. In v2 prüft dbt freshness Quellen und Modelle; dbt source freshness bleibt als Quellen-Unterbefehl erhalten. dbt build führt Source-Freshness-Prüfungen nicht automatisch mit aus. In Plattformjobs lässt die Freshness-Checkbox nachfolgende Schritte selbst bei einem Fehler weiterlaufen; als eigener Run-Schritt kann der Fehler sie stoppen. Die Prüfung meldet eine Verzögerung, startet aber keinen fehlenden Import neu. Freshness-Befehl, Jobverhalten.

Snapshots speichern beobachtete Versionen einer Zeile mit Gültigkeitszeiten. Mit verlässlichem updated_at empfiehlt dbt die Timestamp-Strategie; andernfalls kann ein Spaltenvergleich passen. Bei hard_deletes ist ignore der Standard, invalidate und new_record sind explizite Optionen. Snapshots ignorieren --full-refresh und bewahren so vorhandene Historie. Entscheidend bleibt der Lauftakt: Ändert sich eine Quellzeile zweimal zwischen zwei Snapshots, kann der Zwischenzustand nicht nachträglich rekonstruiert werden. dbt: Snapshots.

Kostenformel statt Gratisetikett

Lokales dbt ist kostenlos; Warehouse, Orchestrierung und Betrieb können kosten. Developer bietet laut dbt-Preisseite gratis einen Sitz, ein Projekt und 3.000 erfolgreiche Modell-Builds monatlich. Starter nennt 100 USD je Nutzer/Monat, fünf Developer-Sitze, ein Projekt, 15.000 Builds und 5.000 abgefragte Metriken monatlich. Die fünf Sitze belegen keine Mindestabnahme. Enterprise-Preise sind individuell.

Beispielrechnung mit offenem Mengengerüst

Eigene Annahme: 20 Läufe täglich mit je 15 erfolgreichen Modell-Builds an 30 Tagen ergeben 20 × 15 × 30 = 9.000 Builds monatlich, oberhalb des Developer-Limits. Starter-Budgetformel: n abgerechnete Sitze × 100 USD/Monat. Falls fünf Sitze abgerechnet würden: 500 USD/Monat. Die Mindestzahl muss ein Angebot klären; eine Buchbarkeit von nur zwei Sitzen ist nicht belegt.

Gesamtformel: Plattform/Sitze + Nutzungsdienste + Warehouse + Ingestion + Betrieb. dbt State kostet laut Preisseite nach Testphase 0,094 USD je täglich eindeutig wiederverwendetem Modell, Test oder Snapshot (DATT), nicht je Build. Wizard wird nach Tokens abgerechnet. Kein gemessener Projektpreis.

Ein synthetischer Fall zeigt die kritischen Grenzen

Der synthetische ETL-Fall beginnt mit ID 1 = 1.000 EUR, ID 2 = 2.000 EUR, ID 3 = 500 EUR; Summe 3.500 EUR. Dann folgt ID 1 als Korrektur auf 1.200 EUR, ID 2 als Hard Delete, ID 4 neu mit 800 EUR und ID 3 als verspätete Korrektur auf 700 EUR. Deren updated_at liegt zurück, ihre event_seq ist höher. Sollstand: IDs 1, 3, 4; Summe 2.700 EUR.

Erstlauf und Replay: Eingabe und Lauf wiederholen. Keine Dubletten, gleiche Schlüssel und Summe; eine alte Version darf die neuere Sequenz nicht überschreiben.
Löschung und Korrektur: ID 2 entfernen und ID 3 trotz altem updated_at anhand höherer event_seq übernehmen. Ein reiner Zeitfilter kann sie verpassen; unique_key löscht ID 2 nicht von selbst.
Fehlerhafter Betrag: Wie in malformed.csv einen nicht numerischen Betrag anliefern. Erwartet sind definierte Ablehnung oder Quarantäne und ein sichtbarer Fehler. Einen negativen Betrag nur dann separat zurückweisen, wenn die fachliche Regel vorab feststeht.
Neue Spalte: currency nur bei neuen Zeilen füllen. Alte NULL-Werte erkennen und Backfill planen.
Snapshotverlust: ID 3 zwischen zwei Snapshot-Läufen zweimal ändern. Ein nicht beobachteter Zwischenstand bleibt verloren; für jede Version braucht es ein vorgelagertes Änderungsprotokoll oder einen hinreichenden Takt.

Gesonderte Gleichsummenfalle: Im Mini-Beispiel mit anderen IDs stehen zunächst a = 1.000, b = 200 und c = 1.500 EUR, zusammen 2.700 EUR. Danach a = 1.200, b gelöscht, c unverändert und d = 0 EUR: weiterhin 2.700 EUR. Eine Summenprüfung allein übersieht b. Schlüssel und Zeilenwerte mitprüfen.

Das sind Sollwerte, kein durchgeführter dbt-Test. Ergebnisse brauchen Version, Adapter, Strategie und Laufprotokoll als Beleg.

Nächste Schritte, Quellen und Beratungsweg

Lege zuerst Edition, Adapter, Warehouse, gewünschte Frische und Löschsemantik fest. Importiere dann die 14 Kriterien in den Anforderungskatalog und passe Muss-Kriterien an den echten Datenfluss an. Ein Pilot sollte mit synthetischen Daten beginnen und Korrektur, Hard Delete, Replay, Tests, Freshness-Alarm und Snapshot-Takt einzeln belegen. Bei einem EU-Betrieb gehören zusätzlich Konto-Region, Zusatzdienste, Datentransfer, Aufbewahrung und Zugriffsrechte in die Prüfung.

Primärquellen für dieses Profil sind die Lizenz-FAQ, das Repository-LICENSE, die Adapterübersicht, die Dokumentation zu inkrementellen Modellen, Snapshots und Freshness sowie Preise und Regionen. Quellenstand ist der 10.10.2026; Tarife und Adapterstände können sich ändern. Herstellerlinks enthalten keine BIS-Partnerkennung. Die Methodik erklärt die Trennung von Herstellerangaben und eigener Prüfung.

Wenn dbt-Daten später in Berichte fließen sollen, hilft unser Power-BI-Profil bei der getrennten Frage nach Darstellung und Leserzugriff. Für die Auswahl und Einrichtung bietet die Schwesterplattform BIC Beratung an. BIS und BIC werden von Axel Schweizer betrieben; daraus ergibt sich ein wirtschaftliches Interesse. Die Verbindung ist unter Finanzierung offengelegt.