Die Kernidee lässt sich in einem Satz zusammenfassen: dbt bringt bewährte Praktiken der Softwareentwicklung in die Welt der Datentransformation. Analysten und Data Engineers schreiben ihre Transformationslogik als SQL-Abfragen, die dbt versioniert, testet, dokumentiert und in der richtigen Reihenfolge im Data Warehouse ausführt. Was früher in einem Gewirr aus manuell gepflegten SQL-Skripten, undokumentierten Views und fragilen Abläufen endete, wird mit dbt zu einem nachvollziehbaren, wiederholbaren und prüfbaren Prozess.
Drei Eigenschaften definieren dbt:
Um dbt richtig einzuordnen, hilft ein Blick auf den typischen Weg der Daten. Zuerst werden Daten aus Quellsystemen – ERP, CRM, Online-Shop, Marketing-Tools – in das zentrale Data Warehouse geladen, meist mit spezialisierten Ladewerkzeugen. Diese Rohdaten sind roh im Wortsinn: unterschiedlich benannt, teils widersprüchlich, ohne einheitliche Geschäftslogik. Erst der zweite Schritt, die Transformation, verwandelt sie in saubere, konsistente und geschäftlich sinnvolle Tabellen – etwa eine verlässliche Kundentabelle oder eine belastbare Umsatzauswertung. Genau dieser zweite Schritt ist die Domäne von dbt. Erst danach greifen die BI-Werkzeuge auf die veredelten Daten zu.
Diese klare Positionierung ist wichtig: dbt ersetzt weder das Data Warehouse noch das Ladewerkzeug noch das BI-Tool. Es füllt die Lücke dazwischen – eine Lücke, die in vielen gewachsenen Datenlandschaften bislang chaotisch oder gar nicht gefüllt war. In der Vergangenheit lebte diese Transformationslogik oft unsichtbar verstreut: in Datenbank-Views, in Skripten einzelner Mitarbeiter, in den Formeln der Berichte. dbt macht diese Logik sichtbar, zentral und pflegbar.
dbt ist eng mit einem Rollenbild verbunden, das erst durch das Werkzeug populär wurde: dem Analytics Engineer. Diese Rolle steht zwischen dem klassischen Data Engineer, der Infrastruktur und Datenflüsse baut, und dem Datenanalysten, der Fragen des Geschäfts beantwortet. Der Analytics Engineer modelliert die Daten – er sorgt dafür, dass aus Rohdaten belastbare, dokumentierte und getestete Analysetabellen werden, auf die sich das ganze Unternehmen verlassen kann. dbt ist das Werkzeug, das diese Rolle überhaupt praktikabel macht, weil eine Person mit SQL-Kenntnissen damit produktiv werden kann, ohne tiefe Programmierkenntnisse in anderen Sprachen zu benötigen.
Für den Mittelstand ist das eine gute Nachricht. Wo große Konzerne ganze Data-Engineering-Teams beschäftigen, kann im Mittelstand oft eine einzelne datenaffine Person – mit SQL-Wissen und der Unterstützung durch dbt – eine erstaunlich professionelle Datenmodellierung aufbauen. Genau das senkt die Einstiegshürde in eine ernsthafte, verlässliche Datenkultur erheblich.
dbt Core ist das quelloffene Herzstück und für viele der Einstieg in die dbt-Welt. Es ist ein Werkzeug, das über die Kommandozeile bedient wird: Man legt ein Projekt an, schreibt SQL-Modelle, definiert Tests und lässt dbt Core die Transformationen im Data Warehouse ausführen. Der große Vorteil ist die Freiheit – dbt Core kostet keine Lizenzgebühren und lässt sich in praktisch jeder Umgebung betreiben, vom Laptop des Analysten bis zum voll automatisierten Ablauf auf einem eigenen Server. Für Unternehmen mit hohen Anforderungen an Datenhoheit ist das ein zentrales Argument, weil die gesamte Verarbeitung in der eigenen, kontrollierten Umgebung bleibt.
Die Kehrseite ist die Eigenverantwortung. Mit dbt Core müssen Sie selbst dafür sorgen, dass die Transformationen regelmäßig und zuverlässig laufen – etwa über einen Orchestrierungsdienst oder einen Zeitplaner. Auch die Zusammenarbeit im Team, die Rechteverwaltung und das Monitoring organisieren Sie selbst, meist mit weiteren Werkzeugen drumherum. Für Teams mit technischer Kompetenz ist das gut beherrschbar; für Teams, die sich ganz auf die Datenmodellierung konzentrieren wollen, kann dieser Betriebsaufwand ins Gewicht fallen.
dbt Cloud nimmt Ihnen genau diesen Betriebsaufwand ab. Es ist ein von dbt Labs betriebener Dienst, der rund um den Core eine ganze Reihe von Komfortfunktionen legt: eine grafische Entwicklungsumgebung im Browser, mit der man ohne lokale Einrichtung sofort loslegen kann; eine integrierte Zeitsteuerung, die Transformationen automatisch nach Plan ausführt; Funktionen für die Zusammenarbeit im Team; sowie Werkzeuge für Überwachung, Berechtigungen und die Anbindung an Entwicklungsprozesse. Der Preis dafür ist ein Abonnement und die Auslagerung des Betriebs an einen externen, US-amerikanischen Anbieter.
Aus Beratungssicht ist die Wahl selten eine Frage von „richtig“ oder „falsch“, sondern eine Abwägung. dbt Cloud verkürzt den Weg zum produktiven Betrieb erheblich und entlastet kleine Teams von Infrastruktur-Arbeit. dbt Core gibt maximale Kontrolle und Kostenfreiheit bei der Lizenz, verlangt dafür aber eigenes technisches Können. Wichtig: Weil beide Varianten denselben Kern teilen, ist ein Wechsel später möglich – die eigentliche Modellierungsarbeit ist nicht verloren, wenn man sich umentscheidet.
In unseren Projekten hängt die Empfehlung von wenigen Faktoren ab. Verfügt ein Unternehmen über technisch versierte Mitarbeiter, die ohnehin mit Git und Automatisierung umgehen, und legt es besonderen Wert auf Kostenkontrolle und Datenhoheit, ist dbt Core oft der bevorzugte Weg – häufig kombiniert mit einem bereits vorhandenen Orchestrierungswerkzeug. Fehlt diese technische Tiefe oder soll ein kleines Team schnell und ohne Infrastruktur-Aufbau produktiv werden, spielt dbt Cloud seine Stärken aus. Ein pragmatischer Mittelweg, den wir häufig sehen: mit dbt Core und schlanker Orchestrierung starten, und erst dann über dbt Cloud nachdenken, wenn das Team wächst und der Betriebsaufwand spürbar wird.
Das Herzstück von dbt sind die Modelle. Ein Modell ist zunächst nichts anderes als eine SQL-Abfrage in einer Datei. Der entscheidende Unterschied zu freien SQL-Skripten: dbt kennt die Beziehungen zwischen den Modellen und führt sie in der richtigen Reihenfolge aus. Ein Modell kann auf ein anderes verweisen, dieses wieder auf ein drittes – dbt löst diese Kette automatisch auf und baut die Tabellen in korrekter Abfolge. So lässt sich eine komplexe Transformation in viele kleine, verständliche und einzeln testbare Schritte zerlegen, statt sie in eine unübersichtliche Monster-Abfrage zu zwängen.
Diese Modularität ist einer der größten praktischen Gewinne. Geschäftslogik – etwa die Definition, was genau ein „aktiver Kunde“ oder ein „abgeschlossener Auftrag“ ist – wird an einer einzigen zentralen Stelle festgelegt und von allen darauf aufbauenden Modellen wiederverwendet. Ändert sich die Definition, wird sie an einer Stelle angepasst und wirkt überall konsistent. Genau das beendet den verbreiteten Zustand, in dem drei Abteilungen drei unterschiedliche Umsatzzahlen präsentieren, weil jede ihre eigene, leicht abweichende Berechnung pflegt.
Zwei Fähigkeiten heben dbt aus der Masse der SQL-Werkzeuge heraus. Die Tests prüfen automatisch die Qualität der Daten: ob ein Schlüssel wirklich eindeutig ist, ob eine Pflichtspalte keine Lücken hat, ob Beziehungen zwischen Tabellen stimmen oder ob Werte in einem erwarteten Bereich liegen. Diese Regeln werden einmal definiert und bei jedem Transformationslauf automatisch geprüft. Schlägt ein Test fehl, wird das sichtbar – idealerweise, bevor fehlerhafte Zahlen in einem Vorstandsbericht landen. Für die Vertrauenswürdigkeit einer Datenlandschaft ist das kaum zu überschätzen.
Die Dokumentation löst ein altbekanntes Problem: Dokumentation, die in separaten Dokumenten lebt, veraltet fast zwangsläufig. Bei dbt werden Beschreibungen von Tabellen und Spalten direkt im Projekt gepflegt, neben der Logik, die sie beschreiben. dbt erzeugt daraus automatisch eine durchsuchbare Dokumentationsseite. Weil Logik und Beschreibung im selben Projekt liegen und gemeinsam versioniert werden, bleibt die Dokumentation nah an der Realität. Neue Teammitglieder finden sich dadurch schneller zurecht, und Fachbereiche können nachschlagen, was eine Kennzahl tatsächlich bedeutet.
Aus den Beziehungen zwischen den Modellen erzeugt dbt automatisch einen Herkunftsgraphen, die sogenannte Data Lineage. Dieser Graph zeigt visuell, welche Quellen in welche Modelle fließen und welche Berichte am Ende darauf aufbauen. Der praktische Nutzen ist enorm: Wenn ein Quellsystem geändert wird, lässt sich sofort erkennen, welche Auswertungen davon betroffen sind. Wenn eine Zahl in einem Bericht seltsam aussieht, lässt sich ihre Herkunft bis zur Quelle zurückverfolgen. Diese Nachvollziehbarkeit ist genau das, was in gewachsenen, undokumentierten Datenlandschaften schmerzlich fehlt – und was dbt fast beiläufig mitliefert.
Die Grundidee der Automatisierung bei dbt ist so alt wie die Softwareentwicklung selbst: Wiederkehrende Abläufe sollen nicht von Hand, sondern verlässlich und wiederholbar von Maschinen erledigt werden. Übertragen auf Daten heißt das: Transformationen laufen nach Plan, jede Änderung wird automatisch getestet, bevor sie produktiv geht, und Fehler werden früh sichtbar. Dieser Ansatz, aus der Softwarewelt als Continuous Integration bekannt, ist einer der Gründe, warum dbt als so verlässlich gilt.
dbt Labs hat mit dbt Copilot eine KI-gestützte Assistenzfunktion in dbt Cloud vorgestellt. Der Anspruch dahinter entspricht dem, was man von KI-Assistenten in der Softwareentwicklung kennt: Unterstützung beim Schreiben von SQL-Modellen, Vorschläge für Tests und Dokumentation sowie Hilfe beim Verstehen bestehender Modelle. In der Praxis kann eine solche Assistenz spürbar Zeit sparen – etwa indem sie einen ersten Entwurf für Beschreibungen liefert oder naheliegende Tests vorschlägt, die man dann nur noch prüft und anpasst.
Aus Beratungssicht ordnen wir das nüchtern ein: KI-Assistenz ist ein vielversprechender Beschleuniger, aber kein Autopilot. Ein von einer KI vorgeschlagenes Modell oder ein generierter Test muss vom fachkundigen Menschen geprüft werden, bevor er produktiv geht – denn ob eine Kennzahl fachlich korrekt definiert ist, kann keine KI verlässlich beurteilen. Wir empfehlen, solche Funktionen als Werkzeug für erfahrene Anwender zu betrachten, das Routinearbeit abnimmt, und nicht als Weg, fehlendes Datenverständnis zu ersetzen. Zudem entwickelt sich diese Funktionsfamilie schnell – der konkrete Umfang sollte beim Anbieter geprüft werden.
Weniger spektakulär, aber im Alltag wirkungsvoller ist die Automatisierung rund um Tests und Auslieferung. Weil ein dbt-Projekt in Git versioniert ist, lässt es sich in moderne Entwicklungsabläufe einbinden. Bevor eine Änderung an den Datenmodellen produktiv wird, kann sie automatisch in einer geschützten Umgebung ausgeführt und getestet werden – die aus der Softwareentwicklung bekannte Idee von Continuous Integration und Continuous Deployment (CI/CD). Erst wenn alle Tests bestanden sind, geht die Änderung live. Das verhindert, dass eine unbedachte Anpassung stillschweigend fehlerhafte Zahlen in die Berichte einspeist.
dbt Cloud bringt für diese Abläufe fertige Bausteine mit, etwa eine integrierte Zeitsteuerung und Prüfläufe bei Änderungen. Mit dbt Core lässt sich dasselbe erreichen, allerdings baut man die Automatisierung mit weiteren Werkzeugen selbst auf. In beiden Fällen gilt: Diese Automatisierung ist einer der größten Reifegewinne, die dbt in eine Datenlandschaft bringt – sie macht aus einem fehleranfälligen manuellen Prozess einen kontrollierten, wiederholbaren Ablauf.
Ein weiterer Baustein, der die Konsistenz erhöht, ist die semantische Schicht. Die Idee: Zentrale Geschäftskennzahlen – etwa „Umsatz“, „Deckungsbeitrag“ oder „aktive Kunden“ – werden an einer einzigen Stelle definiert und stehen dann allen nachgelagerten Werkzeugen konsistent zur Verfügung. So rechnen unterschiedliche Dashboards und Berichte garantiert mit derselben Definition. Das adressiert genau das verbreitete Problem, dass verschiedene Auswertungen leicht abweichende Zahlen liefern, weil jede ihre eigene Berechnung mitbringt. Diese Funktionsfamilie entwickelt sich weiter; ihren konkreten Reifegrad und Funktionsumfang sollte man für den eigenen Anwendungsfall beim Anbieter prüfen.
Der typische Aufbau in unseren Projekten folgt einer klaren Arbeitsteilung: Ein Ladewerkzeug bringt die Rohdaten aus den Quellsystemen ins Warehouse, dbt transformiert sie dort zu sauberen, getesteten und dokumentierten Analysetabellen, und ein BI-Tool stellt die Ergebnisse dar. Weil dbt die Rechenarbeit an das Warehouse delegiert, bleibt es selbst schlank – es erzeugt lediglich die passenden Befehle und lässt die eigentliche Verarbeitung dort laufen, wo die Daten liegen.
dbt braucht ein Data Warehouse, in dem es arbeiten kann – das ist seine Grundvoraussetzung. Es unterstützt die führenden modernen Plattformen, darunter Snowflake, Google BigQuery, Databricks und Amazon Redshift, sowie weitere Datenbanken. Diese Wahl ist bewusst offen gehalten: dbt bindet sich nicht an einen einzelnen Anbieter, sondern spricht die jeweilige SQL-Umgebung an. Das gibt Unternehmen Flexibilität und mindert die Bindung an eine bestimmte Cloud. In der Praxis passt dbt seine erzeugten Befehle an die jeweilige Plattform an – die Modellierungslogik bleibt weitgehend gleich, auch wenn man das darunterliegende Warehouse später wechseln würde.
Für den Mittelstand ist diese Offenheit ein starkes Argument. Wer heute etwa mit BigQuery startet, weil das Unternehmen ohnehin in der Google-Welt zu Hause ist, legt sich mit dbt nicht zusätzlich fest. Die Transformationsschicht bleibt portabel – ein Sicherheitsnetz gegen strategische Fehlentscheidungen bei der Plattformwahl.
dbt lädt selbst keine Daten. Damit Rohdaten überhaupt im Warehouse landen, braucht es eine Ladeschicht. Hier arbeiten Werkzeuge wie Fivetran oder Airbyte Hand in Hand mit dbt: Sie holen Daten aus Standardquellen – ERP- und CRM-Systemen, Datenbanken, Online-Diensten – und spielen sie unverändert ins Warehouse. Erst dann übernimmt dbt und verwandelt diese Rohdaten in verwertbare Analysetabellen. Diese Arbeitsteilung ist so typisch, dass die Kombination aus Ladewerkzeug, Cloud-Warehouse, dbt und BI-Tool oft als „moderner Data Stack“ bezeichnet wird.
In der Praxis ist diese Trennung ein Segen. Jedes Werkzeug tut genau eine Sache gut: Das Ladewerkzeug kümmert sich um die oft fehleranfällige Anbindung vieler Quellen, dbt um die Transformationslogik. Das macht die Gesamtlösung übersichtlicher und leichter wartbar als monolithische Werkzeuge, die alles auf einmal versuchen. Wir gehen auf diese Abgrenzung in Kapitel 06 noch genauer ein.
Am Ende der Kette stehen die BI-Werkzeuge, die die von dbt aufbereiteten Daten für Menschen sichtbar machen. dbt arbeitet grundsätzlich mit allen gängigen BI-Tools zusammen, weil sie schlicht auf die vom Warehouse bereitgestellten, von dbt modellierten Tabellen zugreifen. Ob Microsoft Power BI – im deutschen Mittelstand am weitesten verbreitet –, Tableau, Looker oder ein anderes Werkzeug: Sie alle profitieren davon, dass die eigentliche Geschäftslogik bereits in dbt sauber und zentral abgebildet ist, statt in jedem Bericht neu und potenziell abweichend definiert zu werden.
Genau hierin liegt ein oft übersehener Vorteil. Wenn die Logik in dbt liegt, bleiben die BI-Berichte schlank und konsistent – sie visualisieren nur noch. Die verbreitete Unsitte, komplexe Berechnungen in undurchschaubaren Dashboard-Formeln zu verstecken, entfällt. Das macht die BI-Landschaft nicht nur konsistenter, sondern auch unabhängiger vom einzelnen BI-Werkzeug: Ein Wechsel des Frontends wird deutlich einfacher, wenn die Logik nicht darin gefangen ist.
Der klassische Ansatz der Datenintegration hieß ETL – Extract, Transform, Load. Dabei wurden Daten aus den Quellen gezogen, in einem separaten Schritt vor dem Laden transformiert und erst dann ins Zielsystem geschrieben. Dieser Ansatz stammt aus einer Zeit, in der Speicher und Rechenleistung teuer waren und man Daten sparsam behandeln musste. Mit den leistungsfähigen, verbrauchsbasierten Cloud-Warehouses hat sich das Bild gedreht.
Der moderne Ansatz heißt ELT – Extract, Load, Transform. Hier werden Rohdaten zuerst unverändert ins Warehouse geladen und erst dort transformiert, unter Nutzung der günstigen, elastischen Rechenleistung der Plattform. Genau in diese Welt gehört dbt: Es ist das Werkzeug für das „T“, die Transformation innerhalb des Warehouse. Die Ladewerkzeuge übernehmen das „E“ und „L“ – das Extrahieren aus den Quellen und das Laden ins Warehouse.
Ein häufiges Missverständnis ist, dbt und Ladewerkzeuge wie Fivetran oder Airbyte stünden in Konkurrenz. Das Gegenteil ist der Fall: Sie ergänzen sich. Fivetran und Airbyte sind darauf spezialisiert, Daten zuverlässig aus vielen unterschiedlichen Quellen zu extrahieren und ins Warehouse zu laden – eine Aufgabe, die überraschend fehleranfällig und wartungsintensiv ist, weil sich Schnittstellen und Datenstrukturen der Quellen ständig ändern. dbt übernimmt danach die Transformation dieser geladenen Rohdaten. Die eine Schicht bringt die Daten herein, die andere veredelt sie.
Diese Arbeitsteilung ist kein Zufall, sondern gute Architektur. Jedes Werkzeug konzentriert sich auf das, was es am besten kann. Das Ergebnis ist eine Datenlandschaft aus austauschbaren, spezialisierten Bausteinen statt eines monolithischen Werkzeugs, das alles halbgut macht. Für den Mittelstand bedeutet das auch mehr Verhandlungsspielraum und weniger Abhängigkeit – jede Schicht lässt sich einzeln bewerten und im Zweifel austauschen.
Zur ehrlichen Einordnung gehört auch, klar zu benennen, was dbt nicht leistet. dbt ist kein Ladewerkzeug – es zieht keine Daten aus Quellsystemen. Es ist kein Data Warehouse – es speichert selbst keine Daten dauerhaft, sondern nutzt das darunterliegende Warehouse. Es ist kein BI-Tool – es erzeugt keine Dashboards oder Visualisierungen. Und es ist kein umfassendes Orchestrierungswerkzeug für beliebige Datenflüsse, auch wenn es einfache Zeitsteuerung (in der Cloud-Variante) mitbringt. dbt macht eine Sache – die Transformation im Warehouse – ausgesprochen gut, und überlässt den Rest bewusst spezialisierten Nachbarn.
Die wichtigste Voraussetzung ist ein funktionierendes Data Warehouse, in dem Rohdaten bereits ankommen oder ankommen sollen. dbt ohne Warehouse ist wie ein Motor ohne Fahrzeug – es fehlt die Umgebung, in der es arbeiten kann. Häufig wird dbt daher gemeinsam mit der Einführung eines Cloud-Warehouse und einer Ladeschicht geplant. Steht das Warehouse, folgt die zentrale Betriebsentscheidung: dbt Core im Selbstbetrieb oder dbt Cloud als verwalteter Dienst. Diese Wahl, in Kapitel 02 ausführlich behandelt, prägt den späteren Betriebsaufwand und die Datenhoheit maßgeblich und sollte früh und bewusst getroffen werden.
Für das Self-Hosting von dbt Core braucht es zumindest grundlegende technische Kompetenz: Umgang mit der Kommandozeile, mit Git und mit einem Mechanismus, der die Transformationen regelmäßig ausführt. Wer diese Kompetenz im Haus hat, gewinnt volle Kontrolle und Kostenfreiheit bei der Lizenz. Wer sie nicht hat oder nicht binden möchte, ist mit dbt Cloud oft schneller und ruhiger unterwegs – gegen Abogebühr und mit Blick auf den zu prüfenden Serverstandort.
Der zweite Erfolgsfaktor ist eine durchdachte Projektstruktur. In der dbt-Praxis hat sich eine Schichtung bewährt, die Rohdaten über Zwischenmodelle bis zu geschäftsfertigen Analysetabellen führt. Diese klare Ordnung – vom Rohen zum Fertigen, in benannten, dokumentierten Schritten – verhindert, dass ein dbt-Projekt mit der Zeit im Wildwuchs endet. Aus unserer Erfahrung ist eine von Anfang an saubere Struktur samt Namenskonventionen einer der unterschätzten Erfolgsfaktoren jeder dbt-Einführung; nachträgliches Aufräumen ist deutlich mühsamer.
Wie bei jeder Datenplattform empfehlen wir einen fokussierten Start. Statt sofort alle Datenbereiche modellieren zu wollen, beginnt man mit einem konkreten, schmerzhaften Anwendungsfall – etwa einem verlässlichen Umsatz-Reporting – und baut die Modelle darum herum auf. Das liefert schnell sichtbaren Wert, schafft Akzeptanz und hält den Aufwand überschaubar. Aus dem ersten Erfolg wächst dann die Plattform organisch weiter.
Weil ein dbt-Projekt in Git lebt, kommt automatisch eine gewisse Zusammenarbeits-Disziplin ins Spiel: Änderungen werden nachvollziehbar, überprüfbar und gemeinsam gepflegt. Gerade im Mittelstand, wo oft wenige Personen viele Rollen tragen, ist das ein Gewinn – es entsteht eine gemeinsame, dokumentierte Wahrheit statt individueller Insellösungen. Zugleich empfiehlt sich ein klares Rechtekonzept, das festlegt, wer Modelle ändern darf und wie Änderungen produktiv gehen. dbt macht die Transformation technisch handhabbar; die organisatorische Disziplin – Konventionen, Reviews, Verantwortlichkeiten – müssen Sie selbst mitbringen. Genau an dieser Schnittstelle zwischen Technik, Daten und Organisation setzt unsere Beratungsarbeit an.
Besonders naheliegend ist dbt für Unternehmen, die bereits Daten aus mehreren Quellsystemen in einem Cloud-Warehouse zusammenführen, aber noch keine saubere, konsistente Modellierung darüber gelegt haben. Ein klassisches Beispiel ist ein abteilungsübergreifendes Umsatz- und Deckungsbeitrags-Reporting: Daten aus ERP, CRM und Webshop liegen bereits im Warehouse, aber jede Abteilung berechnet ihre Kennzahlen leicht anders. dbt bündelt diese Logik an einer zentralen, getesteten und dokumentierten Stelle – und plötzlich stimmen die Zahlen über alle Berichte hinweg überein.
Weitere typische Felder sind die Zusammenführung von Marketing-Daten aus verschiedenen Kanälen zu einer belastbaren Auswertung, in der klar wird, welche Ausgaben zu profitablen Kunden führen; der Aufbau einer 360-Grad-Kundensicht aus ERP-, CRM- und Web-Daten; oder die Aufbereitung von Produktions- und Betriebsdaten für ein Management-Reporting. In all diesen Fällen ist dbt nicht das sichtbare Ergebnis – das sind die Dashboards –, aber der Grund dafür, dass man den Dashboards trauen kann.
Ein erster, klar umrissener dbt-Anwendungsfall – vom Aufsetzen des Projekts über die ersten Modelle und Tests bis zum verlässlichen, dokumentierten Analysedatensatz – ist in vielen Mittelstands-Projekten in wenigen Wochen umsetzbar, sofern ein Warehouse mit geladenen Daten bereits vorhanden ist. Der Aufbau einer breiten, unternehmensweiten Modellierung über viele Datenbereiche hinweg ist dagegen ein fortlaufendes Programm über mehrere Monate. Wer mit einem fokussierten Pilotprojekt startet und daraus lernt, baut die Plattform tragfähig aus – statt sich an einem überdimensionierten Erstwurf zu verheben. Wichtig ist die ehrliche Einordnung: dbt ist ein Baustein, kein Rundum-sorglos-Paket, und entfaltet seinen Wert erst im Zusammenspiel mit Warehouse, Ladeschicht und BI-Tool.
Die Kostenfrage bei dbt beantwortet sich zuerst über die Variante. dbt Core ist quelloffen und verursacht keine Lizenzgebühren – Sie „bezahlen“ hier vor allem mit dem eigenen Betriebsaufwand: der Zeit für Einrichtung, Ausführung, Automatisierung und Wartung sowie den Kosten der Infrastruktur, auf der Sie es betreiben. dbt Cloud wird dagegen als Abonnement gebucht; der Anbieter stellt gestufte Pläne mit unterschiedlichem Funktions- und Nutzungsumfang bereit. Konkrete Eurobeträge nennen wir bewusst nicht – die Preise unterscheiden sich je nach Plan, Nutzung und Vertrag und ändern sich über die Zeit. Die verbindlichen Konditionen prüfen Sie bitte direkt beim Anbieter.
Ein oft übersehener Punkt: Die eigentlichen Rechenkosten entstehen nicht in dbt, sondern im Data Warehouse, in dem die Transformationen ausgeführt werden. Ineffizient gebaute Modelle, die bei jedem Lauf riesige Datenmengen verarbeiten, treiben die Warehouse-Rechnung – nicht die dbt-Rechnung. Umgekehrt hilft gute Modellierung, diese Kosten niedrig zu halten. Wer die Gesamtkosten seiner Datenplattform betrachtet, muss dbt-Lizenz (oder Core-Betriebsaufwand), Warehouse-Rechenkosten und Ladeschicht zusammendenken – dbt ist dabei meist der kleinere, gut planbare Posten.
dbt Labs ist ein US-amerikanisches Unternehmen. Für deutsche und europäische Unternehmen wirft das – wie bei allen US-Anbietern – berechtigte Fragen zu Datenschutz und Datenhoheit auf. Entscheidend ist hier eine Besonderheit von dbt: In den allermeisten Konstellationen verarbeitet dbt Ihre eigentlichen Geschäftsdaten nicht selbst, sondern erzeugt nur Befehle, die im Data Warehouse ausgeführt werden. Die Daten bleiben im Warehouse. Das entschärft einen Teil der Problematik – verlagert die zentrale Datenschutzfrage aber auf das Warehouse und dessen Serverstandort.
Für die Bewertung ist die Variante entscheidend. dbt Core im Self-Hosting ist aus Datenhoheits-Sicht die stärkste Option: Es läuft vollständig in Ihrer eigenen, kontrollierten Umgebung, es fließen keine Daten zu dbt Labs, und Sie behalten die volle Kontrolle darüber, wo und wie es ausgeführt wird. Für Unternehmen mit hohen Souveränitätsanforderungen ist Core deshalb oft der bevorzugte Weg. Bei dbt Cloud hingegen betreibt ein US-Anbieter den Dienst; hier sollten Sie den angebotenen Serverstandort prüfen – dbt Labs bietet Optionen an, deren aktuelle Ausgestaltung (etwa EU-Hosting) Sie direkt beim Anbieter erfragen sollten – sowie die vertraglichen Instrumente wie einen Auftragsverarbeitungsvertrag und die etablierten Sicherheitszertifizierungen.
Bestehen bleibt – wie bei allen US-Anbietern – ein grundsätzliches Drittland-Thema, das seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird. Weil dbt in der Regel nur Metadaten und Steuerinformationen, nicht aber die eigentlichen Massendaten verarbeitet, ist das Risikoprofil hier oft günstiger als bei einem Werkzeug, das selbst große Mengen personenbezogener Daten speichert. Für die meisten Mittelständler ist dbt Cloud mit geprüftem Serverstandort, sauberem Auftragsverarbeitungsvertrag und Datenminimierung vertretbar; wer maximale Souveränität braucht, wählt dbt Core im Eigenbetrieb. Die endgültige Bewertung bleibt eine Frage des Einzelfalls.
