TL;DR
Databricks stellt Ihnen zwei Rechnungen: eine für DBUs (Databricks Units) und eine für die Cloud-Infrastruktur – und die beiden lassen sich nicht automatisch abgleichen. Die DBU-Preise variieren je nach Compute-Typ um bis zum 3,5-Fachen, und neuere Funktionen wie Quality Monitors folgen komplett eigenen Abrechnungsmodellen. Drei Maßnahmen verhindern die meisten Kostenüberraschungen: Auto-Termination für jeden Cluster und jedes Warehouse, Job Compute für alle geplanten Workflows und konsistentes Tagging, bevor Sie skalieren. Nichts davon ist kompliziert. Die meisten Teams lassen es trotzdem weg.
Wie funktioniert die Abrechnung bei Databricks eigentlich?
Databricks berechnet Kosten an zwei getrennten Stellen – und die beiden Rechnungen wissen nichts voneinander.
Die erste Rechnung kommt von Databricks selbst. Sie wird in Databricks Units (DBUs) ausgewiesen, einer abstrakten Maßeinheit für die pro Sekunde verbrauchte Rechenkapazität. Der Preis pro DBU hängt davon ab, welche Art von Arbeit Sie ausführen, welchen Cloud-Anbieter Sie nutzen und welche Databricks-Edition Sie erworben haben.
Die zweite Rechnung kommt von Ihrem Cloud-Anbieter (AWS, Azure oder GCP). Hier schlagen die zugrunde liegenden virtuellen Maschinen, Storage und Netzwerk-Egress zu Buche.
Diese doppelte Struktur bringt viele Teams anfangs ins Straucheln. Die System-Tabellen von Databricks liefern eine saubere Kostenaufschlüsselung nach Workload und SKU, doch diese Sicht deckt nur die DBU-Seite ab. Die Infrastrukturkosten stecken in einem separaten Billing-Export, und beides abzugleichen ist alles andere als trivial. Noch schwieriger wird es, wenn Ihre Umgebung Classic- und Serverless-Compute mischt: Classic-Cluster verursachen VM-Kosten auf Ihrer Cloud-Rechnung, während Serverless die Infrastruktur in den DBU-Preis einrechnet. Zwei verschiedene Kostenstrukturen, ein Workspace. Die meisten Teams berücksichtigen die Cloud-Seite erst dann vollständig, wenn die erste unangenehme Rechnung eintrifft.
Die Gesamtbetriebskosten zu verstehen ist eine solche Herausforderung, dass Databricks ein Open-Source-Tool veröffentlicht hat, das genau dabei hilft: https://www.databricks.com/blog/getting-full-picture-unifying-databricks-and-cloud-infrastructure-costs
Was ist eine DBU – und warum schwankt der Preis so stark?
Eine DBU ist eine normalisierte Einheit für Rechenkapazität. Stellen Sie sie sich als Guthaben vor, das verbraucht wird, sobald Compute läuft. Der Haken: Der Dollarwert einer DBU ist nicht fix. Er hängt von drei Faktoren ab:
1. Compute-TypDas ist der größte Multiplikator. Ein geplanter Batch-Job auf Job Compute kostet auf Azure rund 0,15 $/DBU. Derselbe Code, interaktiv auf einem All-Purpose-Cluster ausgeführt, kostet 0,55 $/DBU. Das ist kein kleiner Unterschied, sondern das 3,5-Fache. Teams, die Produktions-Pipelines auf All-Purpose-Clustern laufen lassen, weil "der war halt schon da", zahlen diesen Aufpreis bei jedem einzelnen Lauf.
Hier eine Referenztabelle für Azure (US-Region, Listenpreise):
Vollständige Preise unter databricks.com/product/pricing.
2. Serverless vs. ClassicServerless-Compute hat einen höheren DBU-Preis, weil das Infrastruktur-Management im Preis enthalten ist und auf der Cloud-Seite keine VM-Kosten anfallen. Classic-Compute hat einen niedrigeren DBU-Preis, dafür zahlen Sie die zugrunde liegenden VMs separat. Keine der beiden Varianten ist pauschal günstiger – es hängt vollständig von Ihrem Workload ab.
3. Nicht alles wird in DBUs abgerechnetNeuere Databricks-Funktionen – darunter Data Ingestion, Vektorsuche, KI-Agenten, Quality Monitors und operative Datenbanken – folgen oft ganz anderen Modellen: pro Token, pro gespeichertem GB, pro Stunde Kapazität. Das ist eine der am häufigsten übersehenen Quellen für Rechnungsüberraschungen. Dazu gleich mehr.
Welche versteckten Kosten haben einen Kunden bei Quality Monitors kalt erwischt?
Apropos Nicht-DBU-Kosten: Quality Monitors gehören zu den tückischsten Kostentreibern, die ich in der Praxis gesehen habe.
Bei kleinen Tabellen ist ein Quality-Monitor-Update günstig, typischerweise rund 0,10 $ pro Lauf. Bei großen, historischen Tabellen ohne aktiviertes Change Data Feed (CDF) muss der Monitor jedoch bei jeder Ausführung die gesamte Tabelle scannen. Bei manchen großen Tabellen sind das 20 $ pro Update.
Ein Kunde von mir hatte Quality Monitors über Hunderte von Tabellen hinweg im Einsatz. Rund 95 % davon liefen günstig, kein Problem. Aber eine Handvoll großer Tabellen ohne CDF kostete 20 $ pro Lauf – und das täglich. Allein das machte einen erheblichen Teil der Monatsrechnung aus, und niemand wusste davon, bis wir in unserem Costs Monitoring Dashboard nachgeforscht haben. Das Quality-Monitors-Panel zeigt das nicht prominent an. Man muss gezielt danach suchen.
Die Lösung ist simpel: CDF aktivieren und Zeitreihen- statt Snapshot-Quality-Monitors verwenden. Aber man muss wissen, was man tut.
Das ist auch ein gutes Beispiel dafür, warum "DBU-Kosten" allein nicht das ganze Bild zeigen. Quality Monitors haben eine eigene Abrechnungsdimension, getrennt vom Verbrauch Ihrer Cluster oder Warehouses.
Serverless oder Classic Compute – womit sparen Sie wirklich?
Serverless-Compute kostet pro DBU das 1,5- bis 2-Fache des Classic-Pendants. Das klingt nach der falschen Wahl für kostenbewusste Teams. Meistens ist es das nicht – aber es gibt eine Nuance, die man verstehen sollte.
Das Argument für den Start mit Serverless ist einfach: Es eliminiert eine ganze Klasse von Konfigurationsproblemen. Keine Entscheidungen zur Clustergröße, kein Autoscaling-Tuning, keine Auto-Termination, die man vergessen kann, keine Cluster, die über Nacht im Leerlauf stehen. Der operative Aufwand verschwindet – und bei den meisten Workloads kostet diese Engineering-Zeit mehr als der DBU-Aufpreis.
Die Nuance: Serverless skaliert so effizient, dass Kostensteigerungen schwerer zu erkennen sind. Bei Classic Compute haben Sie eine realistische Erwartung an die Kosten, wenn ein Job konstant eine Stunde dauert. Bei Serverless können zwei Läufe dieselbe Laufzeit haben, aber sehr unterschiedliche Kosten verursachen – weil Serverless bei einem schwereren Workload schnell hochskaliert hat und Sie doppelt so viele DBUs verbraucht haben. Die Dauer bleibt gleich. Die Rechnung verdoppelt sich.
Das heißt nicht, dass Serverless falsch ist. Es heißt, dass Sie ein sauberes Kosten-Monitoring brauchen, nicht nur ein Laufzeit-Tracking. Behalten Sie den DBU-Verbrauch im Blick, nicht nur die Ausführungszeit.
Meine Empfehlung: Starten Sie flächendeckend mit Serverless. Nutzen Sie Ihr Kosten-Monitoring, um die teuren, häufig laufenden Jobs zu identifizieren, die vorhersehbar genug sind, um den Aufwand einer sauberen Classic-Compute-Konfiguration zu rechtfertigen. Optimieren Sie die Ausreißer. Versuchen Sie nicht, alles von Hand zu tunen.
Welche 3 Kostenhebel sollten Sie einrichten, bevor Sie sie brauchen?
Das Preismodell zu verstehen ist nützlich. Den Unterschied macht aber erst, tatsächlich etwas daraus abzuleiten. Hier sind die drei Maßnahmen, die mit dem geringsten Engineering-Aufwand die größte Wirkung erzielen.
1. Auto-Termination für jeden Cluster und jedes Warehouse
Das ist die wirkungsvollste Einzelmaßnahme – und die, die am häufigsten übersprungen wird.
Ohne Auto-Termination bleibt ein Cluster nach getaner Arbeit einfach bestehen und verbraucht DBUs zum vollen Preis, bis ihn jemand manuell stoppt. Der Schaden entsteht meist nicht durch einen einzelnen großen Cluster, sondern durch die Summe vieler Cluster, die jeweils ein paar Stunden zu lange laufen – im ganzen Team, jeden Tag.
Ich habe das zweimal auf denkwürdige Weise schiefgehen sehen.
Der erste Fall: Ein Praktikant trainierte ML-Modelle und konfigurierte einen großen Cluster mit einem Auto-Termination-Fenster von fünf Tagen – in der Annahme, das sei eine vernünftige Obergrenze für einen Trainingslauf. Der Job war nach Stunden fertig. Der Cluster lief weiter. Über einen Monat lang fiel das niemandem auf. Dieser eine Cluster machte 15–20 % der gesamten Databricks-Rechnung für diesen Zeitraum aus.
Der zweite Fall: Eine Pipeline, die stark verschachtelte JSON-Dateien einlas, funktionierte in der Testumgebung einwandfrei. Sie wurde in Produktion deployed. Die Produktionsdateien hatten eine andere Struktur. Die Pipeline schlug nicht fehl – sie lief einfach. Zehn Stunden lang. Jeden Tag. Niemand schaute hin. Sie musste manuell gestoppt und repariert werden. Ein Job-Timeout hätte das schon beim ersten Lauf abgefangen.
So konfigurieren Sie es:
- Interaktive Cluster: Auto-Termination auf 30 Minuten setzen
- SQL Warehouses: Auto-Stop auf 10 Minuten setzen (Serverless Warehouses starten in Sekunden, ein Neustart kostet also kaum etwas)
- Jeder geplante Job: Timeout auf das Doppelte der durchschnittlichen Laufzeit setzen
Ein wichtiger Hinweis: Notebooks haben keinen nativen Timeout-Mechanismus. Ein aktiv ausgeführtes Notebook hält den Cluster unbegrenzt am Leben, weil Auto-Termination nie greift, solange der Cluster nicht im Leerlauf ist. Schon eine Streaming-Abfrage, die in einem Notebook angezeigt wird, reicht aus, um einen Cluster dauerhaft am Laufen zu halten. Der einzige Schutz: die Cluster-Laufzeit über die System-Tabellen überwachen und Alerts für alles einrichten, was länger läuft als erwartet.
2. Job Compute (nicht All-Purpose) für geplante Workflows
Das ist die einfachste Kostensenkung, die die meisten Teams noch nicht umgesetzt haben.
Wenn Sie einen Databricks-Workflow definieren, ist die Versuchung groß, ihn an einen bestehenden interaktiven Cluster zu hängen. Er ist schon da, er ist schon konfiguriert, er funktioniert. Das Problem: Interaktives (All-Purpose-)Compute kostet rund 0,55 $/DBU, während Job Compute bei 0,15 $/DBU (Classic) bzw. 0,35 $/DBU (Serverless) liegt. Bei einer Produktions-Pipeline, die mehrmals täglich läuft, summiert sich diese Differenz schnell.
Der richtige Ansatz ist, Compute als Entscheidung pro Task zu behandeln. Ein Workflow mit einer Python-Transformation gefolgt von einer SQL-Aggregation kann und sollte für den ersten Task Serverless Job Compute und für den zweiten ein SQL Warehouse nutzen. Sie sind nicht auf einen Compute-Typ für den gesamten Workflow festgelegt. Wählen Sie für jeden Task die günstigste passende Option.
Faustregel: Was geplant läuft, gehört nicht auf All-Purpose-Compute.
3. Taggen Sie alles, bevor Sie skalieren
Tags wirken wie eine lästige Routineaufgabe. Tatsächlich sind sie eine Grundvoraussetzung für das Kostenmanagement.
Die System-Tabellen von Databricks liefern Rohdaten zum DBU-Verbrauch. Erst Tags erlauben die Antwort auf die eigentlich wichtige Frage: Welches Team, welches Projekt, welche Pipeline treibt diese Kosten?
Ohne Tags ertrinken Sie in Clusternamen, die sich mit der Zeit ändern (etl_dev, etl_staging, prod_churn_v2), und in Nutzungsdaten, die sich nicht sinnvoll gruppieren lassen. Mit Tags können Sie Kosten per einfacher Abfrage nach Geschäftsbereich, Umgebung und Workflow aufschlüsseln.
Gute Tags für den Anfang:
- Geschäftsbereich: Welches Team verantwortet diesen Workload
- Umgebung: Produktion, Staging, Entwicklung
- Projekt: Welcher Initiative dieser Workload dient
- Workflow-Name: Ein stabiler logischer Name, der Umbenennungen überlebt
Auf AWS und Azure werden Tags außerdem in die Abrechnungsdaten Ihres Cloud-Anbieters übernommen – der einzige zuverlässige Weg, Ihre Databricks-DBU-Kosten mit den Cloud-VM-Kosten auf der anderen Rechnung abzugleichen.
Der praktische Rat: Definieren Sie Ihre Tagging-Taxonomie, bevor Sie Dutzende Pipelines haben. Tags nachträglich in eine gewachsene Umgebung einzuziehen ist mühsam. Eine Handvoll gut gewählter Tags, vom ersten Tag an konsequent angewendet, ist mehr wert als ein ausgefeiltes Schema, an das sich niemand hält.
Für Serverless-Compute gibt es einen zusätzlichen Schritt: Da Serverless keinen persistenten Cluster zum Taggen hat, müssen Sie Serverless Budget Policies konfigurieren, um Tags an die Serverless-Nutzung anzuhängen. Andernfalls landet der Serverless-Verbrauch ohne jeden Zuordnungskontext in Ihren System-Tabellen.
Sie wollen Ihre Databricks-Rechnung um 30 % senken? Unser kostenloses E-Book behandelt Auto-Termination, Job Compute, Budget Policies und 17 weitere Maßnahmen, die Sie sofort umsetzen können. Ohne Schnickschnack – nur die Konfigurationen, die wirklich etwas bewirken. Jetzt kostenloses Exemplar sichern →
Wo fangen Sie an, wenn gerade eine unübersichtliche Databricks-Rechnung vor Ihnen liegt?
Wenn Ihre Databricks-Kosten bereits höher sind als erwartet, ist die schnellste Diagnose eine Abfrage Ihrer System-Tabellen:
Das liefert eine Kostenaufschlüsselung nach Produkt und SKU. Um sie mit den tatsächlichen Workloads zu verknüpfen, joinen Sie system.lakeflow.job_run_timeline hinzu und sehen, welche Jobs die Rechnung treiben.
Worauf Sie konkret achten sollten:
- Jede Nutzung der Interactive Workloads-SKU, die eigentlich auf Job Compute laufen sollte
- Alle Quality-Monitor-Positionen, vor allem bei großen Tabellen
- Cluster oder Warehouses, die im Verhältnis zu ihrer tatsächlichen Arbeit auffällig lange laufen
Denken Sie daran: Diese Sicht deckt nur die Databricks-Seite ab. Die Cloud-VM-Kosten stecken in einem separaten Export Ihres Cloud-Anbieters. In einer gemischten Classic/Serverless-Umgebung müssen beide Sichten separat abgeglichen werden.
Wie behalten Sie die Databricks-Kosten beim Skalieren im Griff?
Die drei genannten Maßnahmen decken die häufigsten Quellen von Verschwendung ab. Damit sie auch bei wachsendem Team und wachsenden Workloads bestehen bleiben, braucht es eine Governance-Ebene:
- Deployen Sie Cluster als Infrastructure as Code, statt Engineers ihre eigenen provisionieren zu lassen. Wenn die Konfiguration in YAML liegt und durch CI/CD läuft, sind Auto-Termination und Tagging immer korrekt gesetzt – weil sie in der Definition erzwungen werden und nicht im Ermessen Einzelner liegen.
- Nutzen Sie Cluster Policies für Teams, die wirklich eigenes Compute erstellen müssen. Policies schränken den Konfigurationsraum ein: Sie können Auto-Termination erzwingen, die Clustergröße deckeln und Instanztypen beschränken – und lassen Engineers trotzdem sinnvollen Spielraum.
- Richten Sie Kosten-Alerts ein – in der Databricks-Account-Konsole oder als eigene Alerts auf Basis der System-Tabellen. Die Standardabweichung der täglichen Kosten pro Workload zu messen ist ein empfindlicheres Frühwarnsignal als ein fester Schwellenwert. So erkennen Sie Abweichungen, bevor sie zum Problem werden.
Kostenoptimierung in Databricks ist kein einmaliges Projekt. Die Plattform entwickelt sich weiter, Teams fügen Workloads hinzu, Datenvolumen wachsen. Teams, die ihre Kosten im Griff behalten, betreiben Monitoring und Kostenzuordnung als kontinuierliche Praxis – nicht als Aufräumaktion, nachdem etwas schiefgelaufen ist.
FAQ
Warum ist meine Databricks-Rechnung höher als erwartet? Der häufigste Grund ist ein falscher Compute-Typ: Produktions-Pipelines, die auf interaktiven All-Purpose-Clustern statt auf Job Compute laufen. All-Purpose-Compute kostet pro DBU bis zum 3,5-Fachen von Job Compute. Der zweithäufigste Grund sind Cluster im Leerlauf ohne gesetzte Auto-Termination. Fragen Sie system.billing.usage gejoint mit system.billing.list_prices ab und sortieren Sie absteigend nach Kosten – der Übeltäter steht meist in den ersten fünf Zeilen.
Was ist der Unterschied zwischen Databricks-DBU-Kosten und Cloud-Infrastrukturkosten? DBU-Kosten erscheinen auf Ihrer Databricks-Rechnung und decken die verbrauchte Rechenkapazität ab. Cloud-Infrastrukturkosten erscheinen auf Ihrer AWS-, Azure- oder GCP-Rechnung und decken die zugrunde liegenden VMs, Storage und Netzwerk-Egress ab. Bei Classic-Clustern fällt beides an. Bei Serverless ist die Infrastruktur im DBU-Preis enthalten, und es gibt keine separate Cloud-VM-Position. Die meisten Teams sehen nur die DBU-Seite – bis zur ersten Rechnung, auf der die Cloud-Seite sie überrascht.
Ist Serverless-Compute in Databricks teurer oder günstiger als Classic? Das hängt vom Workload ab, aber in der Praxis ist Serverless trotz höherem DBU-Preis meist günstiger. Der höhere Preis wird dadurch ausgeglichen, dass keine Cloud-VMs bezahlt werden müssen und keine Leerlaufzeit anfällt – Serverless fährt sofort herunter, sobald die Arbeit erledigt ist. Das Risiko bei Serverless: Kostensteigerungen sind schwerer zu erkennen. Zwei Läufe können gleich lange dauern, aber sehr unterschiedliche DBU-Mengen verbrauchen, wenn ein Workload schwerer war. Überwachen Sie den DBU-Verbrauch, nicht nur die Ausführungsdauer.