dbt Cloud: Was die Plattform zusätzlich zu Dokumentation leistet
Versionsbezug: dbt v2.0 / Python-Linie v1.12 · dbt-Plattform: Release-Tracks · 2026-10-17
Aktuelle Produktgeneration: dbt v2.0. Die Python-basierte v1-Linie ist bei 1.12 stabil; 1.13 ist Beta. Engine, Adapter und Pakete separat prüfen. v1-Beispiele sind keine bestätigte v2-Kompatibilitätszusage.
dbt versions ↗ dbt v2 upgrade guide ↗ Referenz geprüft: 2026-10-17Für gehostete Umgebungen den v1-/v2-Release-Track dokumentieren. Catalog, Mesh, SSO und Berechtigungsfunktionen hängen zusätzlich vom Tarif ab; die Architect-Prüfung nennt keine einzelne Core-Versionsnummer.
dbt release tracks ↗ dbt Architect exam ↗ Referenz geprüft: 2026-10-17
Docs, Catalog, Deployment und CI unterscheiden und ihre Governance-Grenzen anhand eines Produktionsmodells prüfen.
Produktstand: 17.10.2026. dbt v2.0 ist die aktuelle Produktgeneration; die Python-Linie v1.12 bleibt eine getrennte Laufzeit. Für die gehostete Plattform sind v1-/v2-Release-Track, Tarif und Deployment-Umgebung zu dokumentieren. Selbst gehostete Docs und Plattform-Catalog sind unterschiedliche Oberflächen; die Prüfungsreferenz 1.11 ist kein Nachweis für eine aktuelle Produktversion.
Quellen- und Prüfstand: 15. Oktober 2026. Redaktionelle Auswertung öffentlich zugänglicher Herstellerdokumentation, kein Produkttest im Kundentenant. Edition, Version, Region, Connector und GA-/Preview-Status vor einer Zusage erneut prüfen.
Begriffe vor dem Lesen
dbt organisiert datenbanknahe Transformationen als versionierten Code. Die dbt platform, oft als dbt Cloud bezeichnet, ergänzt gehostete Arbeitsabläufe. CI prüft Codeänderungen vor der Übernahme. Ein Deployment-Job führt einen freigegebenen Stand in einer Zielumgebung aus.
Core, Docs und Cloud sind unterschiedliche Entscheidungen
„dbt kann nur statische Dokumentation“ wäre als heutige Aussage zu pauschal. Die aktuelle Dokumentationsübersicht unterscheidet selbst gehostete dbt Docs und den gehosteten Catalog; außerdem hängen Generierung und Darstellung von der dbt-Version ab. Für v2 beschreibt sie unter anderem eine neu gestaltete selbst gehostete Dokumentationsoberfläche mit spaltenweiter Lineage. Die Bezeichnung Core allein beschreibt deshalb nicht den gesamten aktuellen Umfang.
Für den Catalog der dbt-Plattform nennt die Dokumentation Starter, Enterprise und Enterprise+ sowie eine konfigurierte Deployment-Umgebung und einen erfolgreichen Lauf. CI-Jobs aktualisieren diesen Catalog nicht. Für das Kundensystem sind Plan, Version, Release-Track und Betriebsart separat festzuhalten.
Was die gehostete Plattform für Governance beitragen kann
| Bereich | Beitrag | Unsere Abnahmefrage |
|---|---|---|
| Entwicklung und Deployment | Gemeinsame Entwicklungs- und Ausführungsumgebungen mit definierten Verbindungen und Codeversionen | Wer darf produktive Verbindung, Job und freigegebenen Code ändern? |
| Scheduling und Betrieb | Geplante, API-gesteuerte oder verkettete Deploy-Jobs, Laufartefakte und Betriebssignale | Welche Reaktion erfolgt bei Fehler oder veralteten Daten? |
| Continuous Integration | Änderungen und betroffene Abhängigkeiten vor dem Merge bauen und testen | Ist ein fehlgeschlagener Check tatsächlich eine Merge-Sperre? |
| Catalog | Projektressourcen, Produktionsmetadaten und Abhängigkeiten zugänglich machen | Welchen Stand sehen Fachnutzer, und wann wurde er zuletzt erneuert? |
| Semantik und teamübergreifende Modelle | Gemeinsame Definitionen und Schnittstellen als ergänzende Gestaltungsaufgabe | Welche Funktion ist im Plan enthalten, welcher Konsument nutzt die Definition tatsächlich? |
Quellen: Deployment-Umgebungen, Deployment und Job-Betrieb und CI. Die CI-Dokumentation beschreibt den Check im Git-Anbieter; die verbindliche Merge-Regel muss dort passend konfiguriert werden.
Was außerhalb des dbt-Projekts bleibt
Ein dbt-Test belegt die implementierte Regel für seinen Prüfstand. Er belegt weder die fachliche Zustimmung noch die Nutzung aller Daten außerhalb dieses Projekts. Ein dokumentierter Zugriffshinweis ersetzt keine Berechtigung in Snowflake, BigQuery oder Databricks. Externe CRM-Prozesse, lokale Excel-Exporte, Löschfreigaben und unternehmensweite Ausnahmen müssen im Gesamtprozess angeschlossen werden.
Unsere Empfehlung: Für Governance der Analytics-Entwicklung ist die dbt-Plattform ein starker Kandidat, wenn Teams den Code-, Test- und Betriebsprozess tatsächlich gemeinsam nutzen. Für unternehmensweite Governance über viele nicht-dbt-Systeme ist sie ein Baustein; ein Enterprise-Katalog kann den übergreifenden Zusammenhang ergänzen. Selbst betriebenes dbt kann ebenfalls geeignet sein, wenn das Team CI/CD, Veröffentlichung, Identitäten und Betrieb verlässlich selbst übernimmt.
Workshop: Ein Modell bis zur Entscheidung prüfen
Wählt ein produktives Umsatzmodell und einen fachlichen Owner. Lasst einen Test absichtlich fehlschlagen, prüft die Merge-Sperre und anschließend den produktiven Deployment-Stand. Vergleicht Commit, Jobzeitpunkt und sichtbaren Catalog-Stand. Prüft mit einem reinen Lesekonto, ob Definition, Einschränkungen und Ansprechpartner verständlich sind. Entzieht schließlich einen Datenzugriff im Zielsystem und prüft, ob die Dokumentation die Entscheidung nachvollziehbar referenziert.
Für den GAP-Plan erfassen wir jede fehlende Verbindung, ihren Owner, Abnahmekriterium und Aufwand getrennt. So bleibt klar, was dbt liefert und was das Projekt noch implementieren muss.
Versionsstand und weitere Quellen
Die dbt Release Notes dokumentieren im September 2026 auch Namensänderungen rund um dbt v1/v2. Produktnamen und aktuelle Tarifdetails werden vor einer Beschaffung erneut geprüft. Im Radar werden passende Release-Hinweise aufgenommen; sie ersetzen keinen Test des eigenen Release-Tracks.
Grundlage: Welche Rolle dbt spielt. Nächste Entscheidung: Plattformfunktionen im Bestand und Katalogauswahl.
Data catalogs: making governance visible and selecting the right fit
Part 4 of 6
View series