Databricks rechnet Compute in Databricks Units (DBUs) ab, sekundengenau und zusätzlich zur separaten Rechnung Ihres Cloud-Anbieters für Virtual Machines, Storage und Egress. Die Gesamtkosten hängen vom Workload-Typ (Jobs vs. All-Purpose vs. SQL), vom Edition-Tier (Standard, Premium oder Enterprise) und von der Cloud-Plattform ab. Wer produktive Batch-workloads auf All-Purpose-Clustern statt auf Jobs-Clustern fährt, zahlt regelmäßig das Drei- bis Vierfache des Notwendigen. Der Weg zu planbaren Databricks-Ausgaben führt über saubere Workload-Typisierung, Auto-Termination-Policies, Cluster-Governance und kontinuierliches Cost-Monitoring.
Die meisten CloudOps- und FinOps-Teams gehen Databricks mit der Erwartung einer überschaubaren Cloud-Rechnung an. Sie bekommen zwei. Databricks rechnet Compute in seiner eigenen Währung ab – DBUs –, während der Cloud-Anbieter die Virtual Machines, den Storage und den Egress, auf denen diese workloads laufen, separat in Rechnung stellt. Keine der beiden Rechnungen weiß von der anderen.
Diese duale Struktur ist nicht die einzige Komplexität. Der DBU-Verbrauch unterscheidet sich um den Faktor 3 bis 4, je nachdem, ob ein Workload als geplanter Job oder in einem interaktiven Notebook läuft. Edition-Tiers multiplizieren den DBU-Preis erneut. Hinzu kommen regionsübergreifender Datentransfer und Kosten für ungenutzte Cluster – und schon kann ein Team mit absolut vernünftigen workloads monatliche Rechnungen sehen, die 50 bis 200 Prozent über der ursprünglichen Prognose liegen.
Dieser Leitfaden zerlegt jede Kostenkomponente, zeigt, wo Teams zu viel ausgeben, und beschreibt die Monitoring- und Governance-Praktiken, die Databricks von einem finanziellen Wackelkandidaten zu einer planbaren operativen Kapazität machen.
Was ist Databricks Pricing und wie funktionieren die Tarife?
Databricks Pricing folgt einem nutzungsbasierten Pay-as-you-go-Modell rund um Databricks Units (DBUs). Eine DBU ist eine normalisierte Maßeinheit für Rechenleistung, abgerechnet sekundengenau. Der DBU-Tarif wird mit der Anzahl der von einem Workload verbrauchten Einheiten multipliziert – das Ergebnis sind Ihre Databricks-Softwarekosten. Die darunterliegende Infrastruktur rechnet Ihr Cloud-Anbieter separat ab.
Die Plattform bietet auf AWS aktuell drei Edition-Tiers: Standard, Premium und Enterprise. Auf Azure und GCP sind Standard und Premium weiterhin verfügbar, allerdings hat Microsoft das Aus für den Standard-Tier auf Azure für Oktober 2026 angekündigt. Neue AWS- und GCP-Kunden starten inzwischen mit Premium als Basis-Tier. Jedes Upgrade liefert zusätzliche Governance-, Sicherheits- und Optimierungsfunktionen und erhöht entsprechend den DBU-Preis.
Standard, Premium und Enterprise: Was ist in welchem Tier enthalten?
Standard deckt grundlegendes Data Engineering und kollaborative Notebooks ab. Databricks SQL Workspace und SQL-Optimierungstools fehlen. Premium ergänzt Unity Catalog für Data Governance, rollenbasierte Zugriffskontrollen, SQL-Analytics-Funktionen sowie die Audit- und Compliance-Features, die die meisten Enterprise-Teams brauchen. Enterprise bringt dedizierten Support, fortgeschrittene Tools für den ML-Lebenszyklus und individuell verhandelte Konditionen für zugesagten Verbrauch.
Die Tier-Entscheidung ist aus zwei Gründen wichtig: Funktionsumfang und Kostenbasis. Ein Team, das ausschließlich automatisiertes ETL fährt, kann auf Standard bleiben. Wer SQL-Analytics für BI-Anwender, Governance über mehrere Workspaces hinweg oder Data-Lineage-Tracking braucht, kommt um Premium nicht herum. Die meisten mittelgroßen Organisationen landen bei Premium und sollten ihre Basiskostenmodelle auf diesen Tarifen aufbauen.
Verbrauchsbasierte Preise vs. Commitments mit Rabatt
On-Demand-Preise erfordern keine Vorabverpflichtung und eignen sich für Teams, die ihre Workload-Muster noch ausloten. Commitments (auf Azure: Databricks Commit Units, kurz DBCUs) bieten spürbare Rabatte im Tausch gegen 1- oder 3-Jahres-Verbrauchsgarantien. Azure bewirbt für ein 3-Jahres-DBCU-Commitment Einsparungen von bis zu 37 Prozent. AWS und GCP bieten vergleichbare Strukturen über ihre jeweiligen Marketplace-Verträge.
Die praktische Schwelle für ein Commitment ist klar: Wenn Ihr Team konstante, planbare workloads betreibt und mindestens 6 Monate Nutzungshistorie als Prognosegrundlage hat, lohnen sich Commitments. Sind workloads noch im Wandel oder saisonal, erkauft On-Demand Flexibilität mit einem Aufpreis. Databricks stellt für jeden Cloud-Anbieter einen Pricing-Calculator bereit, mit dem sich der DBU-Verbrauch vor einem Commitment modellieren lässt.
Was kostet Databricks tatsächlich? Eine vollständige DBU-Aufschlüsselung
Databricks ohne Verständnis der Workload-Typen zu budgetieren, ist der häufigste Weg zum Rechnungsschock. Der Compute-Typ hinter einem Workload bestimmt den DBU-Tarif – und die Spanne ist groß genug, um sich auf jeder Monatsrechnung niederzuschlagen.
DBU-Preise nach Workload-Typ
Jobs Compute fährt geplante, automatisierte workloads: ETL-Pipelines, Datenqualitätsprüfungen, Batch-Aggregationen. Cluster starten mit dem Job und beenden sich nach Abschluss. Das ist die günstigste Compute-Kategorie. All-Purpose Compute unterstützt interaktive Arbeit in geteilten Notebooks, explorative Analysen und Entwicklung. Diese Cluster laufen, bis jemand sie stoppt. Der Aufschlag für den interaktiven Modus spiegelt das reale Idle-Time-Risiko: Ein All-Purpose-Cluster, den ein Data Scientist über Nacht laufen lässt, kostet die ganze Nacht Geld.
Databricks SQL Warehouses bedienen BI-Abfragen und SQL-Analytics. Serverless SQL Warehouses enthalten die zugrunde liegenden VM-Kosten im DBU-Tarif – das vereinfacht die Rechnung, lässt den DBU-Preis aber höher wirken. Bei sporadischem Abfragevolumen spart Serverless oft Geld, weil Idle-Cluster-Kosten entfallen. Bei gleichmäßigen, hochvolumigen SQL-workloads liefert ein klassisches Warehouse auf Reserved Instances meist die bessere Wirtschaftlichkeit.
Ungefähre DBU-Tarife nach Workload-Typ (AWS, Standard- und Premium-Tier)
Compute-Typ
Standard-Tier
Premium-Tier
Geeignet für
Jobs Compute (AWS)
~$0,07/DBU
~$0,15/DBU
Geplantes ETL, Batch-Pipelines
All-Purpose Compute (AWS)
~$0,40/DBU
~$0,55/DBU
Interaktive Notebooks, Dev-Arbeit
SQL Warehouse (AWS)
~$0,22/DBU
~$0,22/DBU
BI-Abfragen, SQL-Analytics
Serverless SQL (AWS)
N/A
~$0,75/DBU*
Sporadische/spitzenlastige SQL-Loads
*Serverless-Tarife enthalten die zugrunde liegenden VM-Kosten. Stand der Tarife: März 2026; aktuelle Werte vor der Budgetierung auf der Databricks Pricing Page verifizieren, da Tarife je nach Region, Instance-Typ und Cloud-Anbieter variieren und sich ändern können.
Die praktische Konsequenz: Produktives ETL auf einem All-Purpose-Cluster statt auf einem Jobs-Cluster zu betreiben, kann die DBU-Rechnung für diesen Workload um das 3- bis 4-Fache erhöhen, ohne dass sich am zugrunde liegenden Compute etwas ändert. Solche workloads zu identifizieren und neu einzuordnen, ist meist der Optimierungsschritt mit dem höchsten ROI, den ein CloudOps-Team angehen kann.
Storage, Datentransfer und zusätzliche Servicekosten
Cloud-Infrastrukturkosten kommen oben auf die DBU-Position. Jeder Databricks-Cluster läuft auf provider-managed VMs, und diese werden zu Standardtarifen abgerechnet. Auf Azure schlägt ein Small-SQL-Compute-Cluster mit etwa 2,64 USD pro Stunde an DBUs und weiteren 3,89 USD pro Stunde an VM-Kosten zu Buche – die tatsächlichen Stundenkosten liegen damit bei über 6,50 USD und damit mehr als doppelt so hoch wie die reine DBU-Zahl. Wer nur über den Databricks-Pricing-Calculator budgetiert und die Cloud-Infrastrukturseite ausblendet, unterschätzt die monatlichen Gesamtkosten regelmäßig um 50 bis 200 Prozent.
Datentransfer kommt als weitere Schicht hinzu. Daten zwischen Regionen zu bewegen, löst Egress-Gebühren beim Cloud-Anbieter aus. Delta-Lake-Storage auf S3, ADLS oder GCS verursacht Object-Storage- und Transaktionskosten. Erweiterte Features wie Delta Live Tables, Unity Catalog Storage und AI Foundation Model Serving bringen jeweils eigene Abrechnungsdimensionen mit. Insbesondere Serverless-Features tragen höhere DBU-Tarife, weil sie den Aufwand für das Infrastrukturmanagement in den Stückpreis einrechnen.
Wie optimieren Sie Databricks-Kosten, ohne das Engineering auszubremsen?
Databricks-Kostenoptimierung ist kein einmaliges Audit. Workloads wachsen, neue Pipelines kommen hinzu, Teams experimentieren. Die Optimierungspraktiken, die unter dieser Dynamik Bestand haben, sind die, die in Cluster-Policies, Architekturmuster und Monitoring-Infrastruktur eingebaut sind – nicht die, die irgendwo auf einer Wiki-Seite verstauben.
Right-Sizing von Cluster-Konfigurationen und automatische Skalierung
Der erste Hebel ist die Workload-Typ-Zuordnung. Jeder produktive Batch-Job, der auf All-Purpose Compute läuft, ist vermeidbarer Aufwand. Per Cluster-Policies Jobs Compute für geplante workloads zu erzwingen, eliminiert diese Kategorie von Waste removal systematisch. Cluster-Policies schränken zudem die Auswahl der Instance-Typen ein, deckeln den DBU-Verbrauch pro Cluster nach oben und verhindern das Ad-hoc-Provisionieren überdimensionierter Nodes.
Die Wahl der Instance-Familie ist die zweite Right-Sizing-Dimension, die die meisten Teams nicht ausschöpfen. Die hauseigene Cost-Optimization-Dokumentation von Databricks ordnet Workload-Typen Instance-Familien zu: memory-optimiert für ML und workloads mit viel Shuffle, compute-optimiert für Structured Streaming und Wartungsjobs wie OPTIMIZE und VACUUM, storage-optimiert für interaktive und gecachte Analysen, GPU-Instanzen ausschließlich für workloads mit GPU-beschleunigten Bibliotheken. Wer für alle workloads standardmäßig auf General-Purpose-Instanzen setzt, verschenkt relevantes Preis-Leistungs-Potenzial.
Auto-Termination ist die dritte zentrale Stellschraube. All-Purpose-Cluster für interaktive Arbeit brauchen aggressive Termination-Schwellen, typischerweise 15 bis 30 Minuten Idle-Zeit, um Übernachtkosten durch eine einzige vergessene Notebook-Session zu vermeiden. Eine wichtige Einschränkung: Standard-Cluster-Autoscaling stößt beim Herunterskalieren von Structured-Streaming-workloads an Grenzen. Genau für diese workloads empfiehlt Databricks Lakeflow Spark Declarative Pipelines mit Enhanced Autoscaling. Wer allgemeine Autoscaling-Empfehlungen ohne diese Unterscheidung auf Streaming-Pipelines anwendet, riskiert Cluster, die nicht wie erwartet herunterskaliert werden.
Spot-Instanzen sind ein weiterer Hebel zur Kostensenkung für fehlertolerante Batch-workloads. Alle drei Cloud-Anbieter unterstützen Spot Pricing für Databricks-Cluster, und die Einsparungen sind erheblich – häufig 60 bis 80 Prozent gegenüber On-Demand-VM-Tarifen. Der Trade-off ist das Unterbrechungsrisiko, das Spot für zeitkritische Pipelines unbrauchbar, für nächtliche Batch-Jobs mit eingebauter Retry-Logik aber sehr effektiv macht.
Das Storage-Format ist ein Kostenhebel, den die meisten Teams komplett übersehen. Pipelines auf Delta Lake statt direkt auf Parquet, ORC oder JSON laufen zu lassen, reduziert die Compute-Laufzeit. Die Performance-Optimierungen von Delta Lake beschleunigen die ETL-Ausführung, was kürzere Cluster-Laufzeiten und weniger DBUs für dieselbe Datenmenge bedeutet. Wer Nicht-Delta-Pipelines übernommen hat, sollte eine Format-Migration als legitime Kostenmaßnahme behandeln, nicht nur als Zuverlässigkeits- oder Governance-Upgrade.
Auch die Defaults für Attached Storage sind eine oft übersehene Kostenposition. Databricks provisioniert mit jedem Cluster standardmäßig EBS-Volumes (oder das jeweilige Pendant für Block Storage auf Azure und GCP), und die Default-Größen sind großzügig bemessen. Die meisten workloads brauchen das nicht. Solange ein Job keine schweren Shuffle-Operationen, kein Memory-Spillage auf Disk oder erheblichen temporären Storage-Bedarf hat, sind diese Volumes provisioniert, abgerechnet und ungenutzt. Default-Volume-Konfigurationen über Cluster-Policies hinweg zu auditieren und Attached Storage für Jobs, die ihn nicht nutzen, zu reduzieren oder zu entfernen, ist eine Maßnahme mit geringem Aufwand, die sich über jeden Cluster im Workspace summiert.
Photon-fähige Runtimes senken den DBU-Verbrauch zusätzlich, indem sie die Query-Ausführung für geeignete workloads beschleunigen. Die Photon-Engine senkt nicht den DBU-Preis, sie erledigt aber dieselbe Berechnung in weniger Sekunden und reduziert so die abgerechneten Einheiten. Alle SQL Warehouses enthalten Photon standardmäßig. Bei Batch-Pipelines erfordert die Aktivierung von Photon auf Jobs-Compute-Clustern eine Bewertung pro Job, da der Speedup je nach Workload-Charakteristik variiert.
Cost-Monitoring, Alerting und Chargeback-Strategien
Teams können nicht steuern, was sie nicht sehen. Databricks stellt Nutzungsdaten auf Workspace- und Cluster-Ebene über System Tables und Cost-Logging-Integrationen bereit. Ohne diese Daten in eine Cost-Analytics-Schicht zu ziehen, die Verbrauch auf Teams, Projekte oder Geschäftseinheiten abbildet, bleiben Optimierungsgespräche zu abstrakt, um Veränderungen anzustoßen.
Tag-Enforcement auf Workspace- und Cluster-Ebene macht Chargeback überhaupt erst möglich. Wenn jeder Cluster ein Cost-Center- oder Projekt-Tag trägt, können Finance und Engineering konkrete Posten statt aggregierter Rechnungen besprechen. Diese Konkretheit verschiebt das Gespräch von "Wir haben zu viel für Databricks ausgegeben" zu "Die ETL-Pipeline für Feature X hat 40 Prozent des Jobs-Compute-Budgets im letzten Monat verbraucht." Solche Gespräche führen zu Handlungen.
Alerts auf DBU-Verbrauchsanomalien liefern die Frühwarnschicht. Schwellenwert-basierte Alerts auf Tages- oder Wochen-DBU-Ausgaben fangen entgleiste Cluster ab, bevor sie sich über mehrere Tage zu Überschreitungen aufaddieren. Budget-Alerts, die an Workspace-Tags hängen, geben einzelnen Teams die Verantwortung für ihre Ausgaben. Attribution plus Alerting plus wöchentlicher Review-Rhythmus macht aus Cost-Management eine kontinuierliche Praxis statt eines Aufräumprojekts.
Databricks Intelligence von DoiT liefert diese Visibility-Schicht out of the box und kombiniert Echtzeit-DBU-Cost-Monitoring mit Anomalieerkennung, Workload-Attribution und automatisierten Governance-Empfehlungen. Teams, die es zusammen mit Cloud Analytics einsetzen, können Databricks-Ausgaben mit Business-KPIs und Engineering-Velocity-Metriken korrelieren. So bekommt FinOps den Kontext, um Verschwendung von produktiver Investition zu unterscheiden.
Databricks vs. Alternativen: Wo liefert die Plattform den besten Mehrwert?
Beim Plattformvergleich für Databricks geht es nicht um die plakativen DBU-Tarife. Es geht um Total Cost of Ownership über den gesamten Stack: Infrastruktur, Betrieb, Personal und die Passung zu Ihrer bestehenden Architektur.
Plattformvergleich: Databricks vs. wichtige Alternativen
Plattform
Preismodell
Stärke
Zu beachten
Databricks
DBU + Cloud-Infra (zwei Rechnungen)
Vereinheitlichtes Lakehouse, ML-/Spark-workloads
DBU-Modell erfordert laufendes Cost-Management
AWS EMR
EC2-Instance-Stunden + EMR-Aufschlag
Niedrigere Kosten pro Job; Multi-Framework-Flexibilität
Höherer operativer Aufwand; weniger Developer-UX
Google Dataproc
VM-Stunden + Dataproc-Aufschlag (~1 Cent/vCPU/Std.)
Schnelles Provisioning (~90 Sek.); GCP-nativ
Bester Wert nur innerhalb des GCP-Ökosystems
Azure Synapse
DWU/cDWU oder serverless verarbeitete Bytes
Tiefe Microsoft-Integration; vereinheitlichtes BI+Spark
Steile Lernkurve; durchwachsene Zuverlässigkeit bei Skalierung
AWS EMR bietet niedrigere Compute-Kosten pro Job für Spark-lastige Batch-workloads, bringt dafür aber mehr operative Komplexität an die Oberfläche. Wer EMR betreibt, investiert in der Regel in dediziertes Cluster-Management, Tuning und Troubleshooting – Arbeit, die Databricks über seine Managed Infrastructure übernimmt. Ein mittelgroßes Analytics-Team, das monatlich 10 TB verarbeitet, gibt für Databricks (inklusive AWS-Infrastruktur) zwischen 8.000 und 12.000 USD aus, gegenüber 5.000 bis 8.000 USD für äquivalente AWS-native Services – allerdings mit deutlich höherem operativen Aufwand im zweiten Szenario.
Google Dataproc provisioniert Hadoop- und Spark-Cluster in rund 90 Sekunden zu konkurrenzfähigen VM-Tarifen mit kleinem Aufschlag für den Managed Service. Für Teams, die tief im GCP-Ökosystem verankert sind, ist das kosteneffizient – allerdings fehlt das vereinheitlichte Analytics-Plattform-Erlebnis (Notebooks, SQL Workspace, Delta Lake, Unity Catalog), das Databricks liefert. Wer sich für Dataproc entscheidet, baut mehr von der umliegenden Toolchain selbst zusammen.
Azure Synapse integriert sich eng mit Power BI, Azure Data Lake Storage und dem Microsoft-Identity-Stack und ist damit die natürliche Wahl für Organisationen, die bereits auf Azure laufen und in T-SQL verankert sind. Serverless- und dedizierte SQL-workloads bewältigt es gut, komplexe Data-Engineering-Pipelines und ML-workloads erfordern jedoch oft zusätzliches Tooling oder die Rückintegration zu Databricks.
Databricks kostet pro DBU mehr als reine Infrastruktur-Alternativen. Dieser Aufpreis finanziert aber eine vereinheitlichte Plattform, die Toolchain-Komplexität, Onboarding-Zeit für Engineers und den operativen Aufwand getrennter Systeme für Data Engineering, Analytics und ML reduziert. Ob sich dieser Trade-off lohnt, hängt vom Workload-Mix und vom Reifegrad Ihres Engineerings ab.
Wie halten Top-Teams ihre Databricks-Ausgaben auch im großen Maßstab planbar?
Die Komplexität von Databricks Pricing ist nicht per se ein Finanzrisiko. Sie wird zu einem, wenn Teams keine Sicht darauf haben, was den Verbrauch treibt, keine Governance über die Cluster-Konfiguration ausüben und Cost-Reviews als Quartalsereignis statt als kontinuierliche Praxis behandeln.
Teams, die Databricks-Ausgaben erfolgreich steuern, teilen einige strukturelle Eigenschaften. Sie trennen Workload-Typen by Design, nutzen Jobs Compute standardmäßig für Produktions-Batches und All-Purpose nur für interaktive Entwicklung. Sie erzwingen Cluster-Policies, die Instance-Auswahl und Idle-Verhalten begrenzen. Sie pflegen Cost-Attribution pro Team über Tags und prüfen Verbrauchsdaten in einem wöchentlichen Rhythmus, um Anomalien abzufangen, bevor sie sich aufaddieren.
Diese operative Disziplin skaliert auch ohne Vollzeit-FinOps-Stelle. Die richtige Monitoring-Infrastruktur bringt die Signale ans Licht. Governance-Tooling setzt Leitplanken, ohne das Engineering auszubremsen. Praxiserprobte Expertise übersetzt Verbrauchsmuster in konkrete Anpassungen, während sich workloads weiterentwickeln.
DoiT vereint Visibility, Governance und Expertise in einer einzigen Plattform. Teams, die Databricks im großen Maßstab betreiben, nutzen Databricks Intelligence, um Cost-Monitoring und Anomalieerkennung zu automatisieren, und arbeiten mit den Cloud-Experten von DoiT zusammen, um Verbrauchsmuster in Optimierungsempfehlungen zu übersetzen. Das Ergebnis: Databricks-Ausgaben, die mit dem Datenwachstum skalieren, ohne finanzielle Volatilität zu erzeugen.
Sehen Sie, wie DoiT CloudOps- und FinOps-Teams dabei unterstützt, Databricks-Ausgaben kontinuierlich zu optimieren, ohne Innovation auszubremsen. Sprechen Sie mit einem Experten.
Häufig gestellte Fragen zu Databricks Pricing
Was ist eine Databricks Unit (DBU)?
Eine DBU ist eine normalisierte Einheit für Rechenleistung, mit der Databricks den Compute-Verbrauch misst und abrechnet. Der DBU-Verbrauch akkumuliert sich sekundengenau, solange ein Cluster läuft, zu einem Tarif, der nach Instance-Typ, Workload-Typ (Jobs, All-Purpose, SQL) und Edition-Tier variiert. Verbrauchte DBUs multipliziert mit dem geltenden DBU-Tarif ergeben Ihre Databricks-Softwarekosten. Diese erscheinen auf einer separaten Rechnung, getrennt von den Infrastrukturkosten Ihres Cloud-Anbieters.
Warum enthält meine Databricks-Rechnung Posten von zwei verschiedenen Anbietern?
Databricks rechnet seine Plattform-Software in DBUs ab. Ihr Cloud-Anbieter (AWS, Azure oder GCP) stellt die Virtual Machines, den Storage und den Netzwerk-Egress, auf denen Ihre Databricks-workloads laufen, separat in Rechnung. Die beiden Rechnungen sind unabhängig, und keiner der Anbieter sieht die Posten des anderen. Wer nur über den Databricks-Pricing-Calculator budgetiert und die Cloud-Infrastrukturseite ausblendet, unterschätzt die monatlichen Gesamtkosten regelmäßig um 50 bis 200 Prozent.
Wie viel kostet Databricks pro Monat für ein typisches Team?
Ein kleines Team, das täglich ETL und Ad-hoc-Analysen auf AWS fährt, gibt typischerweise 1.500 bis 3.000 USD pro Monat aus, kombiniert über Databricks-DBUs und Cloud-Infrastruktur. Mittelgroße Teams mit höheren Datenvolumen und komplexeren workloads liegen häufig bei 5.000 bis 15.000 USD pro Monat oder mehr. Die Gesamtkosten hängen vom Workload-Volumen, der Compute-Typ-Auswahl, dem Edition-Tier, dem Cloud-Anbieter und davon ab, wie gut das Idle-Cluster-Verhalten gesteuert wird. Die Variable mit dem größten Einfluss ist, ob produktive Batch-workloads auf Jobs Compute oder auf All-Purpose Compute laufen.
Was ist der schnellste Weg, Databricks-Kosten zu senken?
Drei Maßnahmen liefern die größten Einsparungen bei minimalem Engineering-Risiko: produktive Batch-workloads von All-Purpose Compute auf Jobs Compute verschieben (senkt die DBU-Kosten dieser workloads typischerweise um 60 bis 75 Prozent), Auto-Termination auf allen All-Purpose-Clustern mit einer Idle-Schwelle von 15 bis 30 Minuten erzwingen und Spot-/Preemptible-Instanzen für fehlertolerante Batch-Jobs nutzen. Zusammen können diese drei Änderungen die Databricks-Gesamtausgaben in Teams, die sie bisher nicht angewendet haben, um 40 bis 60 Prozent reduzieren.
Unterscheidet sich Databricks Pricing zwischen AWS, Azure und GCP?
Ja. Jobs Compute im Standard-Tier kostet auf AWS rund 0,07 USD pro DBU, auf GCP 0,10 USD und auf Azure 0,15 USD. All-Purpose Compute liegt bei den Anbietern enger beieinander, bei rund 0,40 USD pro DBU im Standard-Tier. Azure verursacht zusätzlich Managed-Storage-Kosten für Disks und Blobs, und die nativen Microsoft-Integrationen erschweren direkte Cloud-übergreifende Kostenvergleiche. Enterprise-Tier-Preise basieren auf individuell verhandelten Konditionen und werden bei keinem Anbieter öffentlich gelistet.