Databricks Pricing einfach erklärt: wie deine Rechnung zustande kommt
Die Kernaussagen auf einen Blick.
- Databricks kostet keinen Pauschalpreis, sondern rechnet nach Verbrauch ab: Bezahlt wird die tatsächlich genutzte Rechenleistung, gemessen in einer eigenen Einheit namens DBU.
- Auf jede Databricks-Rechnung kommt eine zweite, getrennte Rechnung deiner Cloud für Rechenleistung, Speicher und Datenverkehr.
- Es gibt keine feste Laufzeit und keinen Mindestvertrag: Abgerechnet wird sekundengenau nach tatsächlichem Verbrauch, und läuft kein Compute, entstehen keine DBU-Kosten.
Inhaltsverzeichnis
Warum die Databricks-Preisliste allein dich nicht weiterbringt
Die erste Databricks-Rechnung liest sich für viele wie ein Rätsel. Da stehen DBUs, verschiedene Compute-Typen, eine Zeile für Jobs, eine für SQL, dazu eine völlig getrennte Position von Azure oder AWS. Am Ende eine Summe, die niemand im Budget-Gespräch sauber erklären kann. Die Frage „Warum ist das so teuer?" bleibt unbeantwortet, weil die Rechnung zwar jede Position auflistet, aber nicht die Logik dahinter.
Ein Blick auf die offizielle Preisseite hilft nur begrenzt. Dort stehen Listenpreise pro DBU, gestaffelt nach Edition und Workload. Was fehlt, ist die Rechenlogik: Wie viele DBUs verbraucht ein täglicher Job? Warum taucht die Cloud noch einmal separat auf? Ist Serverless jetzt teurer oder günstiger? Die Pricing-Kalkulatoren der Anbieter liefern zwar Zahlen, erklären aber nicht, was hinter ihnen steckt.
Das Ergebnis kennt jeder, der schon einmal ein Datenplattform-Budget verantwortet hat:
Wie kommt die Summe zustande und stimmt sie überhaupt? Was davon ist Databricks, was ist die Cloud? An welchen Stellen läuft die Rechnung nächsten Monat aus dem Ruder? Und was davon lässt sich überhaupt beeinflussen?
Die gute Nachricht: Die Databricks-Preislogik wirkt komplizierter, als sie ist. Hinter jeder Rechnung stehen vier Faktoren und eine klare Trennung zwischen der Databricks-Gebühr und deiner Cloud-Rechnung. Wer diese Mechanik einmal verstanden hat, liest jede Databricks-Rechnung und kann sie grob schätzen.
Was ist eine DBU? Die Recheneinheit hinter jeder Rechnung
Eine DBU (Databricks Unit) ist der Verbrauchszähler der Plattform. Sie misst, wie viel Rechenarbeit ein Cluster oder ein SQL Warehouse pro Zeiteinheit leistet. Man kann sie sich vorstellen wie den Zählerstand für Strom: Bezahlt wird die tatsächlich abgerufene Leistung über die Zeit, so wie ein Stromzähler die verbrauchten Kilowattstunden zählt. Ein kleiner Cluster verbraucht wenige DBUs pro Stunde, ein großer viele.
Databricks rechnet sekundengenau nach tatsächlichem Verbrauch ab, und die DBU ist die Einheit, in der dieser Verbrauch gemessen wird. Zwei Dinge folgen daraus. Erstens: Es gibt keinen pauschalen Stundenpreis. Ein Cluster, der doppelt so groß ist, kostet pro Stunde etwa doppelt so viele DBUs. Zweitens: Abgerechnet wird sekundengenau, solange Compute läuft. Ein Cluster, der vergessen wird und über Nacht weiterläuft, zählt die ganze Zeit mit.
Die DBU-Menge allein sagt aber noch nichts über den Preis. Erst die Rate macht daraus einen Betrag, und die Rate hängt davon ab, was du fährst. Genau das ist der Punkt, an dem die meisten Rechnungen unlesbar werden: DBUs sind nicht gleich DBUs.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche Bestandteile hat eine Databricks-Rechnung?
Jede einzelne Position auf der Databricks-Seite deiner Rechnung entsteht aus demselben Bauplan. Vier Faktoren, multipliziert:
DBU-Menge × DBU-Rate × Compute-Typ × Edition.
Der Reihe nach, in verständlich:
DBU-Menge
Wie viel Rechenarbeit wurde geleistet? Das hängt an Cluster-Größe und Laufzeit. Größerer Cluster oder längere Laufzeit heißt mehr DBUs. Auch größere Datenmengen und komplexere Abfragen erhöhen die DBU-Menge.
DBU-Rate
Der Preis pro DBU in Geld. Keine feste Zahl: Sie hängt von Cloud, Region, Produkt und Edition ab, und ist der Wert, der sich am häufigsten ändert.
Compute-Typ
Wofür läuft die Rechenleistung? Data Engineering ist meist am günstigsten, Interactive Workloads am teuersten. Dieselbe Arbeit kostet je nach Produkt ein Vielfaches pro DBU.
Edition
Standard, Premium oder Enterprise. Jede Stufe schaltet mehr Sicherheits- und Governance-Funktionen frei und hat eine höhere DBU-Rate.
Databricks staffelt die DBU-Preise nach Produktbereich: Data Engineering für geplante Datenverarbeitung, Data Warehousing für SQL-Abfragen und Dashboards, Interactive Workloads für die Arbeit im Notebook, dazu Artificial Intelligence und Operational Database. Innerhalb jedes Bereichs macht es zusätzlich einen Unterschied, ob das Compute klassisch oder serverless läuft. Die meisten Unternehmen im regulierten Umfeld fahren Premium oder Enterprise, weil Funktionen wie feingranulare Zugriffskontrolle daran hängen.
Diese vier Faktoren erklären die meisten Überraschungen auf der Rechnung. Wenn ein produktiver Job auf All-Purpose Compute statt auf Jobs Compute läuft, wird dieselbe Arbeit deutlich teurer. Wenn ein Cluster größer dimensioniert ist als nötig, steigt die verbrauchte DBU-Menge entsprechend mit. Wer diese Logik verstanden hat, erkennt schneller, ob ein Kostenanstieg am Compute-Typ, an der Cluster-Größe, an der Laufzeit oder an der gewählten Produktkategorie liegt.
Die Produktbereiche bestimmen anschließend, welche DBU-Rate angewendet wird. Die vollständigen Preise je Produkt findest du weiter unten in der Übersicht. Für die meisten Data- und BI-Vorhaben sind vor allem Jobs Compute, All-Purpose Compute und SQL Warehouses relevant. Artificial Intelligence und Operational Database folgen teilweise eigenen Abrechnungslogiken und werden meist erst dann wichtig, wenn Modelle produktiv betrieben oder operative Datenbank-Workloads auf Databricks umgesetzt werden.
Warum kommen zwei getrennte Rechnungen?
Der häufigste Aha-Moment beim ersten Blick auf die Kosten: Es gibt zwei getrennte Rechnungen. Das gehört zur Struktur des Modells und ist kein Abrechnungsfehler.
Databricks verursacht in der Regel zwei Kostenarten. Die Databricks-Kosten entstehen über DBUs und decken die Nutzung der Plattform ab, also zum Beispiel Workflows, SQL Warehouses, Jobs, Cluster-Funktionen und Optimierungen. Zusätzlich fallen Cloud-Kosten beim jeweiligen Anbieter an, etwa für virtuelle Maschinen, Speicher in S3, ADLS oder GCS und Datenverkehr zwischen Regionen oder Clouds.
Für die Kostenbetrachtung reicht deshalb ein Blick auf die Databricks-Rechnung allein nicht aus. Eine vollständige Sicht verbindet DBU-Verbrauch aus Databricks mit den Infrastrukturkosten aus Azure, AWS oder Google Cloud.
Wie stark die Cloud-Position ins Gewicht fällt, hängt vom Compute-Modell ab. Und damit sind wir bei der Entscheidung, die diese Trennung am stärksten prägt: Serverless oder Classic.
zwei Wege, wie abgerechnet wird
Databricks-Compute fällt grob in zwei Betriebsmodelle: Classic Compute und Serverless Compute. Der wichtigste Unterschied liegt darin, wo die Rechenleistung bereitgestellt wird und welche Kostenpositionen dadurch entstehen.
Bei Classic Compute laufen die virtuellen Maschinen in deinem eigenen Cloud-Konto: Databricks berechnet dafür DBUs, der Cloud-Anbieter separat die Infrastruktur. Bei Serverless Compute stellt Databricks die Rechenleistung aus einer verwalteten Umgebung bereit. Die Infrastruktur steckt bereits in der DBU-Rate.
Classic Compute wählen, wenn
- Workloads planbar sind und den Cluster durchgängig gut auslasten
- volle Kontrolle über Clustergröße, Konfiguration und Netzwerkumgebung gebraucht wird
- das Team Cluster aktiv überwachen und bei Nichtnutzung stoppen kann
Serverless Compute wählen, wenn
- Workloads kurz, schwankend oder interaktiv sind
- schnelle Startzeiten und weniger Betriebsaufwand wichtiger sind als Feinsteuerung
- Leerlauf und falsche Dimensionierung vermieden werden sollen
| Frage | Classic Compute | Serverless Compute |
|---|---|---|
| Wo läuft der Compute? | im eigenen Cloud-Konto | in einer von Databricks verwalteten Umgebung |
| Kostenmodell | DBUs plus Cloud-Infrastruktur | Serverless-DBUs inklusive Infrastruktur |
| DBU-Rate | niedriger | höher |
| Startzeit | Cluster muss starten | meist deutlich schneller |
| Kontrolle | mehr Kontrolle über Konfiguration | weniger Infrastrukturaufwand |
| Risiko | Leerlauf und falsche Dimensionierung | höhere Rate, weniger Feinsteuerung |
| Passt gut für | planbare, gut ausgelastete Jobs | kurze, schwankende oder interaktive Workloads |
Wie sich das sauber vergleichen lässt, ordnen wir im Detail zu Serverless-Compute und seiner Abrechnung ein.
Alle Databricks-Produkte und ihre Preise im Überblick
Die folgende Übersicht listet die wichtigsten Databricks-Produkte je Produktgruppe mit ihrem DBU-Preis. Alle Werte sind Listenpreise für Plan Premium, Cloud AWS, Region Europe (Frankfurt), Stand Juli 2026. In anderer Cloud, Region oder Edition weichen sie ab. Die Spalte „Cloud-Kosten separat?" zeigt, ob zur DBU-Rate noch eine getrennte Cloud-Rechnung für Rechenleistung dazukommt (Ja, typisch bei Classic-Produkten) oder ob die Infrastruktur schon in der Rate steckt (Nein, bei Serverless).
| Produktgruppe | Produkt | Preis | Cloud-Kosten separat? | Was drin ist / Hinweise |
|---|---|---|---|---|
| Data Engineering | Lakeflow Connect: Managed Connectors | 0,39 $/DBU | Nein | Vorgefertigte Konnektoren für Geschäftssysteme; 100 DBU/Workspace/Tag frei |
| Data Engineering | Lakeflow Connect: Zerobus Ingest | 0,056 $/GB | Nein | Serverless-Ingest-API direkt in Delta Lake |
| Data Engineering | Lakeflow Connect: Zerobus OTEL Ingest | 0,087 $/DBU | Nein | Ingest von OpenTelemetry-Daten |
| Data Engineering | Lakeflow Jobs: Classic | 0,15 $/DBU | Ja | Selbstverwaltete Cluster |
| Data Engineering | Lakeflow Jobs: Serverless | 0,39 $/DBU | Nein | Vollständig verwaltet |
| Data Engineering | Lakeflow Spark Declarative Pipelines: Serverless | 0,39 $/DBU | Nein | Streaming- und Batch-Pipelines |
| Data Warehousing | Databricks SQL: Classic | 0,22 $/DBU | Ja | Selbstverwaltetes SQL Warehouse für interaktives SQL |
| Data Warehousing | Databricks SQL: Pro | 0,72 $/DBU | Ja | Erweiterte SQL-Funktionen für ETL/ELT, Data Science und ML |
| Data Warehousing | Databricks SQL: Serverless | 0,91 $/DBU | Nein | Verwaltet und elastisch für hohe Parallelität |
| Interactive Workloads | All-Purpose Compute: Classic | 0,55 $/DBU | Ja | Interaktives Data Science und ML im Notebook |
| Interactive Workloads | All-Purpose Compute: Serverless | 0,79 $/DBU | Nein | Verwaltet und elastisch |
| Artificial Intelligence | Model Serving: CPU | 0,084 $/DBU | Nein | Modelle, Features und Agenten live bereitstellen |
| Artificial Intelligence | Model Serving: GPU | 0,084 $/DBU | Nein | Zusätzlich GPU-DBU-Rate je Instanz und Stunde (z. B. Small/T4 10,48, Large 8×80GB 628,00) |
| Artificial Intelligence | AI Functions (Parse, Extract, Classify) | 0,084 $/DBU | Nein | Unstrukturierte Dateien wie PDFs in strukturierte Delta-Tabellen überführen |
| Artificial Intelligence | AI Search: Standard | 0,34 $/Stunde + 0,250 $/GB-Monat | Nein | Vektor-Index, 2 Mio. Vektoren je Einheit; erste 30 GB Speicher frei |
| Artificial Intelligence | AI Search: Storage Optimized | 1,54 $/Stunde + 0,050 $/GB-Monat | Nein | Vektor-Index, 64 Mio. Vektoren je Einheit; für großskalige RAG-Anwendungen |
| Artificial Intelligence | Agent Bricks: Knowledge Assistant | 0,180 $/Antwort | Nein | Nur für Antworten mit Wissensbasis-Zugriff; Aufbau und Nutzung der Wissensbasis extra |
| Artificial Intelligence | Agent Bricks: Supervisor Agent | 0,084 $/DBU | Nein | Plus alle Sub-Agenten zu ihren jeweiligen Preisen |
| Artificial Intelligence | Genie | 0,084 $/DBU | Ja | Natürlichsprachige Abfragen; 150 DBU/Nutzer/Monat frei |
| Artificial Intelligence | AI Gateway | 0,60 $/GB (Inference Tables), 0,120 $/GB (Usage Tracking) | Nein | Logging und Monitoring von Modell-APIs; Abrechnung in 1-GB-Schritten |
| Operational Database | Lakebase: Compute | 0,110 $/Capacity Unit Hour (Always-On min. 0,083) | Nein | Postgres-Datenbank, skaliert auf null |
| Operational Database | Lakebase: Storage | 0,375 $/GB-Monat | Nein | Fehlertolerante, verteilte Datenbank-Speicherung |
| Apps und Plattform | Databricks Apps | 0,79 $/DBU | Nein | Data- und AI-Apps nativ in Databricks; Governance über Unity Catalog |
Drei Punkte fallen in der Preisübersicht besonders auf.
Erstens ist Serverless pro DBU teurer als Classic Compute. Der Vergleich über die DBU-Rate allein greift aber zu kurz, weil bei Serverless die Infrastruktur bereits enthalten ist. Bei Classic Compute kommen die VM-Kosten des Cloud-Anbieters zusätzlich dazu. Ob Serverless am Ende teurer oder günstiger ist, hängt deshalb vom Workload ab. Gerade bei kurzen, schwankenden oder interaktiven Workloads können weniger Leerlauf, schnellere Starts und weniger Betriebsaufwand die höhere Rate ausgleichen. Wann sich das rechnet, ordnen wir im Detail zu Serverless Compute und seiner Abrechnung ein.
Zweitens gibt es bei einigen Produkten kostenlose Kontingente, die kleinere Workloads bereits abdecken. Beispiele sind Lakeflow Connect mit 100 DBU pro Workspace und Tag oder Genie mit 150 DBU pro Nutzer und Monat.
Drittens sind einige Preise durch befristete Rabatte reduziert. Diese Rabatte können den Listenpreis vorübergehend senken, sollten aber nicht als dauerhafte Kostenbasis eingeplant werden.
Für den Beispiel-Monat weiter unten verwenden wir die Raten aus dieser Übersicht.
ein Beispiel-Monat für eine ETL-Pipeline mit ML und BI-Dashboard
Das Herzstück des Guides ist eine durchgerechnete Monatsrechnung, Schritt für Schritt und nachrechenbar. Statt einer Einzelposition nehmen wir einen kompletten Anwendungsfall, der über drei Produktbereiche läuft.
Das Szenario: Abwanderungs- und Potenzial-Scoring für den Vertrieb. Ein mittelständischer B2B-Händler will jeden Morgen im Dashboard sehen, welche Bestandskunden abzuwandern drohen und wo das größte Zusatzpotenzial liegt. Drei Quellsysteme liefern die Daten, die in einer Medallion-Architektur von Bronze über Silver nach Gold aufbereitet werden. Darauf berechnet ein Modell die Kunden-Scores, und der Vertrieb arbeitet im BI-Dashboard mit dem Ergebnis.
Die Pipeline läuft als stündlicher Batch-Job, rund um die Uhr:
Ingestion (Data Engineering)
Drei Quellen (CRM, Auftragssystem und Web-/Marketing-Daten) sind über Lakeflow Connect angebunden, rund 10 GB pro Quelle und Tag, zusammen etwa 30 GB täglich. Stündlich landen die neuen Daten roh in der Bronze-Schicht.
Aufbereitung (Data Engineering)
Lakeflow Declarative Pipelines führen die Daten von Bronze über Silver (bereinigt, dedupliziert, verknüpft) nach Gold (Kunden-Aggregate). Im selben Lauf werden die Features berechnet und das Modell per Batch-Inferenz angewendet: Jeder Kunde bekommt stündlich einen frischen Score.
Serving (Artificial Intelligence)
Ein Model-Serving-Endpoint hält das Modell für Ad-hoc-Abfragen aus dem Dashboard bereit, etwa für Was-wäre-wenn-Szenarien im Vertrieb.
Dashboard (Data Warehousing)
Ein SQL Warehouse bedient das AI-/BI-Dashboard, mit dem fünf Vertriebler täglich arbeiten.
Die Annahmen (Beispielraten, Stand Juli 2026, Premium-Edition; Raten variieren nach Cloud und Region, bitte aktuell prüfen):
- Ingestion über Lakeflow Connect Managed Connectors (Serverless): rund 1 DBU pro Stunde, also etwa 24 DBU pro Tag. Das bleibt unter dem kostenlosen Kontingent von 100 DBU pro Workspace und Tag, kostet hier also nichts (darüber: 0,39 $ pro DBU)
- Bronze→Silver→Gold plus Features und Inferenz über Lakeflow Declarative Pipelines (Serverless): 6 DBU pro Stunde, Rate 0,39 $ pro DBU (Infrastruktur inklusive), Laufzeit rund 0,25 Stunden pro Lauf
- Model Serving (CPU-Endpoint, Serverless): 4 DBU pro Stunde, Rate 0,084 $ pro DBU (Cloud-Instanz inklusive)
- SQL Warehouse (Databricks SQL Serverless, kleinste Größe 2X-Small): 4 DBU pro Stunde, Rate 0,91 $ pro DBU (Cloud-Instanz inklusive). Größere Warehouses skalieren die DBU-Menge entsprechend, wie die SQL-Warehouse-Kosten im Detail zeigen
Und die Nutzung:
- Ingestion und Aufbereitung laufen stündlich, rund um die Uhr: 24 × 30 = 720 Läufe im Monat.
- Der Model-Serving-Endpoint ist während der Geschäftszeiten aktiv und skaliert nachts auf null: rund 12 Stunden an 22 Arbeitstagen, also 264 Stunden im Monat.
- Das SQL Warehouse läuft dank Auto-Stop nur bei echten Abfragen: effektiv rund 40 Stunden im Monat.
Daraus ergibt sich die Rechnung:
| Position | Produktbereich | Menge | Rate | Databricks-Anteil | Cloud-Anteil |
|---|---|---|---|---|---|
| Ingestion (Lakeflow Connect Managed Connectors) | Data Engineering | 24 DBU/Tag, im Free-Tier | 0,39 $ | 0,00 $ | inklusive |
| Bronze→Silver→Gold plus Features und Inferenz (Declarative Pipelines Serverless) | Data Engineering | 6 × 0,25 × 720 = 1.080 DBU | 0,39 $ | 421,20 $ | inklusive |
| Model Serving (CPU-Endpoint, Serverless) | Artificial Intelligence | 4 × 264 = 1.056 DBU | 0,084 $ | 88,70 $ | inklusive |
| SQL Warehouse (Databricks SQL Serverless, 2X-Small) | Data Warehousing | 4 × 40 = 160 DBU | 0,91 $ | 145,60 $ | inklusive |
| Speicher und Datenverkehr | – | pauschal | – | – | 25,00 $ |
| Summe | 655,50 $ | 25,00 $ |
Gesamt: rund 681 $ im Monat.
Erstens läuft in diesem Beispiel fast alles serverless. Deshalb siehst du fast nur eine Rechnung. Die Cloud-Infrastruktur steckt schon in den DBU-Raten, der einzige separate Cloud-Posten ist mit 25 $ die Speicherung der Daten. Hättest du die Aufbereitung stattdessen auf Classic Compute gelegt, käme eine zweite, oft größere Cloud-VM-Position dazu, genau die Trennung aus dem Abschnitt zu den zwei Rechnungen.
Zweitens dominiert die stündliche Aufbereitung die Rechnung: 421,20 $ für die Declarative Pipelines, mehr als die Hälfte der Gesamtkosten. Der Grund ist die Kombination aus Rund-um-die-Uhr-Betrieb mit 720 Läufen und der Serverless-Rate von 0,39 $ pro DBU. Das SQL Warehouse (145,60 $, Data Warehousing) und das Model Serving (88,70 $, Artificial Intelligence) fallen deutlich kleiner aus, und die Ingestion kostet dank Free-Tier nichts.
Drittens zeigt die Aufbereitung den Serverless-Kompromiss. Die 0,39 $ pro DBU sind deutlich mehr als die 0,15 $ auf einem Classic-Cluster, dafür entfallen VM-Verwaltung, Leerlauf und die separate Cloud-Rechnung. Bei einem stündlichen, kurzen Batch lastet ein Classic-Cluster nie voll aus und zahlt die VM-Zeit trotzdem, sodass Serverless bei diesem Profil oft günstiger herauskommt. Bei dauerhaft ausgelastetem Compute kann Classic vorn liegen.
Viertens ist die Zahl schätzbar und wächst mit dem Geschäft. Zehn Vertriebler statt fünf treiben das SQL Warehouse, ein zusätzliches Quellsystem die Ingestion, häufigeres Echtzeit-Scoring das Model Serving. Jede Änderung lässt sich einem Produktbereich und einer Zeile zuordnen. Genau das leistet ein Kalkulator nicht, der nur eine Endzahl zeigt.
Welche Stellschrauben treiben die Databricks-Kosten?
Nicht jede Einstellung wirkt sich gleich stark auf die Kosten aus. In den meisten Databricks-Setups erklären ein paar wenige Entscheidungen schon einen großen Teil der Rechnung.
Compute-Typ
Geplante Jobs sollten nicht dauerhaft auf All-Purpose Compute laufen. Für produktive Verarbeitung ist Jobs Compute meist der günstigere Weg. In frühen Setups bleiben Notebooks oder Pipelines oft unnötig auf interaktiven Clustern.
Cluster-Größe
Ein größerer Cluster ist nicht automatisch der bessere. Bringt mehr Worker kaum Tempo, wird nur mehr Rechenleistung ohne Nutzen bezahlt. Auto-Scaling fängt Lastspitzen ab, ohne dauerhaft für den Maximalfall zu zahlen.
Leerlauf
Ein Cluster, der läuft, aber nichts tut, kostet trotzdem. Auto-Stop sollte deshalb nicht optional sein, vor allem bei interaktiven Clustern von Analysten oder Entwicklern.
Photon
Beschleunigt Abfragen deutlich, kostet aber mehr pro DBU. Entscheidend ist die Laufzeit, nicht der Preis pro DBU allein: ist ein Workload mit Photon klar schneller, rechnet sich der höhere Faktor oft.
Serverless
Höhere DBU-Rate, dafür entfallen VM-Kosten, lange Startzeiten und Leerlauf. Passt gut zu kurzen, schwankenden Workloads. Bei dauerhaft ausgelasteten Jobs kann Classic weiterhin günstiger sein.
Was Photon technisch macht, erklären wir im Glossar zu Photon.
Diese Punkte sollten nicht nur einmal geprüft, sondern als Plattformregeln umgesetzt werden: Welche Compute-Typen dürfen Teams nutzen? Welche Clustergrößen sind erlaubt? Wann greift Auto-Stop? Und welche Workloads gehören auf Serverless? Wie solche Vorgaben plattformweit durchgesetzt werden, zeigen wir im Überblick zu Cluster Policies und Kosten-Governance. Die tatsächlichen Verbrauchsdaten lassen sich anschließend über System Tables auswerten.
Wo wird die Databricks-Kostenrechnung komplizierter?
Dieser Guide erklärt die Mechanik, damit du deine Rechnung lesen und einen Monat überschlagen kannst. Er ist bewusst kein vollständiges Optimierungs-Handbuch. Ein paar Punkte gehören zur Ehrlichkeit dazu.
Preise ändern sich
Jede Zahl in diesem Guide ist ein Beispiel mit Stand Juli 2026. DBU-Raten unterscheiden sich zwischen Clouds, Regionen und Editionen. Für die eigene Kalkulation zählt immer die aktuelle Rate.
Commitments und Rabatte fehlen
Vorab-Zusagen auf Verbrauch und individuelle Enterprise-Konditionen verändern die effektive DBU-Rate teils erheblich. Hier wird bewusst mit Listenpreisen gerechnet.
Editionen im Detail fehlen
Welche Funktion an Standard, Premium oder Enterprise hängt, ist eine eigene Matrix. Für die Kostenlogik reicht: höhere Edition, höhere Rate, mehr Governance.
Systematische Optimierung fehlt
Verbindliche Regeln, Budget-Alarme, Tagging und Monitoring gehören in den laufenden Plattformbetrieb. Databricks bringt dafür eigene Budget- und Monitoring-Werkzeuge mit.
Fazit
Databricks-Kosten werden verständlich, sobald klar ist, woraus sie entstehen: aus der Databricks-Nutzung, dem gewählten Compute-Modell und den zusätzlichen Cloud-Kosten.
Es gibt nicht den einen festen Stundenpreis. Entscheidend ist, welche Workloads laufen, wie viel Rechenleistung sie verbrauchen und ob diese Rechenleistung sinnvoll gewählt ist.
Dieses Verständnis ist besonders wichtig vor der ersten Plattformentscheidung, bei Budgetplanungen und nach unerwartet hohen Rechnungen. Wer die wichtigsten Kostentreiber kennt, kann Angebote besser einordnen, Budgets realistischer planen und früh erkennen, welche Workloads aus dem Rahmen laufen.
Für kleine, gelegentliche Workloads reicht oft eine einfache Kontrolle. Sobald mehrere Teams Databricks nutzen, Kosten monatlich schwanken und niemand die Haupttreiber erklären kann, braucht es ein klares Betriebsmodell für Kostensteuerung.
Einen typischen Monat durchrechnen, die größten Kostenpositionen identifizieren und diese regelmäßig über die Abrechnungsdaten prüfen.
Wisst ihr, wo eure Databricks-Kosten wirklich entstehen?
- welche Kostenpositionen bei Databricks wirklich relevant sind
- welche Workloads, Cluster oder SQL Warehouses die größten Treiber werden
- wie Classic, Serverless, Cloud-Infrastruktur und Betrieb sinnvoll geschätzt werden
- wie ein belastbares Cost Estimate für euren Databricks-Aufbau oder Plattformausbau aussehen kann
FAQ
Das hängt an Nutzung und Compute-Wahl. Eine vollständige, serverless betriebene Pipeline aus stündlicher Datenaufbereitung, Model Serving und einem BI-Dashboard für fünf Vertriebler landet als Beispiel bei rund 681 $ im Monat (Stand Juli 2026, Listenpreise). Die Summe setzt sich aus dem Databricks-Anteil in DBUs und der getrennten Cloud-Rechnung für Speicher zusammen. Über die Beispiel-Tabelle in diesem Guide lässt sich das mit eigenen Zahlen überschlagen.
