Sie können die Kosten Ihres Databricks Serverless SQL Warehouse senken, indem Sie jedes Workload-Problem dem passenden Stellhebel zuordnen. Auto-Stop reduziert inaktive Laufzeit, die Warehouse-Größe beeinflusst die Performance einzelner Queries, und Max Clusters steuert, wie viel Parallelität das Warehouse abfangen kann.
Die Herausforderung: Diese Signale werden oft vermischt. Ein Warehouse, das zwischen kurzen Jobs aktiv bleibt, braucht nicht mehr Rechenleistung. Workloads, die auf Kapazität warten, brauchen womöglich mehr Cluster statt eines größeren Warehouses. Auch Power BI DirectQuery kann weiterhin Databricks-SQL-Aktivität erzeugen, selbst wenn das SQL selbst bereits gut optimiert ist.
Dieser Artikel zeigt Ihnen, wie Sie diese Fälle auseinanderhalten, Serverless mit Pro und Classic anhand der Gesamtkosten statt nur des DBU-Preises vergleichen und die Einstellung wählen, die zum tatsächlich beobachteten Verhalten passt. Diese Entscheidungen auf Warehouse-Ebene sind Teil des vollständigen Frameworks zur Databricks-Kostenoptimierung, in dem Sizing, Auslastung, Kostenzuordnung und Automatisierung ineinandergreifen.
TL;DR
- Auto-Stop reduziert Leerlauffenster zwischen SQL-Lastspitzen.
- Die Warehouse-Größe bestimmt die Rechenleistung für einzelne Queries.
- Max Clusters steuert, wie viel gleichzeitige Last das Warehouse bedienen kann.
- Serverless, Pro und Classic müssen anhand der Workload-Gesamtkosten verglichen werden, nicht nur anhand des DBU-Preises.
- Der Power-BI-Verbindungsmodus kann die SQL-Warehouse-Aktivität spürbar verändern, wenn
DirectQueryfür eine Aktualität genutzt wird, die das Business gar nicht benötigt.
Warum Startvorgänge und Leerlaufzeiten die Kosten Ihres Databricks SQL Warehouse treiben
Ihre SQL-Warehouse-Rechnung kann schneller wachsen, als die Query-Laufzeit vermuten lässt, denn auch kurze Jobs verursachen Startvorgänge und aktive Zeitfenster. Geplante Alerts machen das Problem leicht übersehbar: Mehrere Queries unter einer Minute auf separaten Zeitplänen können ein Databricks Serverless SQL Warehouse deutlich länger aktiv halten, als das SQL selbst läuft. Die Konfiguration kann diese Lücke noch vergrößern. In einem dokumentierten Bundle-Deployment fehlte auto_stop_mins, was zu einem Wert von 120 Minuten führte – obwohl die aktuelle Dokumentation der Databricks Declarative Automation Bundles für Serverless einen Standardwert von 10 Minuten nennt.
Unsere Einschätzung: Ein versteckter Konfigurationsfehler kann mehr Schaden anrichten als eine einzelne langsame Query, weil er sich bei jedem Lauf wiederholt. Wie viel Ihrer SQL-Warehouse-Rechnung stammt aus teuren Queries – und wie viel aus Einstellungen, die niemand mehr überprüft hat? Dasselbe Muster zeigt sich in den fünf Gewohnheiten, die eine Databricks-Rechnung bewegen, und im vollständigen Framework zur Kostenoptimierung.
Databricks-SQL-Warehouse-Typen: Serverless vs. Pro vs. Classic
Von den wichtigsten SQL-Warehouse-Typen hat Serverless den höchsten sichtbaren DBU-Satz (Databricks Unit), weil der Preis die zugrunde liegende Infrastruktur bereits enthält. Ein Pro SQL Warehouse hat einen niedrigeren DBU-Satz, Classic den niedrigsten – beide berechnen die Cloud-Infrastruktur jedoch separat. Bei Serverless Compute verwaltet Databricks die zugrunde liegende Infrastruktur, statt Ihnen eine separate Infrastrukturposition zur Verwaltung zu überlassen.
Beispielsweise liegen die veröffentlichten AWS-Premium-Listenpreise in US East Stand 2026 bei etwa 0,70 USD pro DBU für Serverless, 0,55 USD für ein Pro SQL Warehouse und 0,22 USD für Classic. Die tatsächlichen Preise können je nach Cloud, Region, Edition und Vertrag variieren. Diese Zahlen gelten für ein regionales Preisbeispiel, zeigen aber, warum der DBU-Satz allein nicht verrät, welche Option insgesamt günstiger ist.
| Typ | Relativer DBU-Satz | Infrastruktur-Abrechnung | Kaltstart | Am besten geeignet für |
|---|---|---|---|---|
| Serverless | Am höchsten | Inklusive | Typischerweise Sekunden | Sprunghafte, interaktive BI- und DirectQuery-Workloads |
| Pro | Mittel | Separat abgerechnet | Typischerweise Minuten | Planbare BI-Workloads, die Pro-Funktionen benötigen |
| Classic | Am niedrigsten | Separat abgerechnet | Typischerweise Minuten | Planbare, zeitgesteuerte Workloads |
Serverless SQL Warehouses eignen sich besser für sprunghafte Last, weil sie innerhalb von Sekunden starten und schnell auf Laständerungen reagieren. Databricks SQL Serverless nutzt zudem Intelligent Workload Management (IWM), um den Ressourcenbedarf von Queries vorherzusagen und die Kapazität bei wechselnder Last zu steuern. Das reduziert die Notwendigkeit, Compute nur deshalb warmzuhalten, um lange Startzeiten zu vermeiden.
Pro SQL Warehouses und Classic SQL Warehouses sind relevanter, wenn die Last planbar ist. Databricks empfiehlt diese SQL Warehouses für geplante Import- oder Extract-Jobs, bei denen sich der Bedarf leichter planen lässt und ein schneller Start weniger wichtig ist. Ein Pro SQL Warehouse bietet Funktionen über Classic SQL hinaus, das für einfachere Anwendungsfälle die Option mit dem niedrigeren DBU-Satz bleibt.
Der sinnvolle Vergleich sind die Gesamtkosten des Workloads – inklusive Infrastruktur, Startverhalten und der Zeit, die das Warehouse aktiv bleiben muss. Wer nur auf den DBU-Satz schaut, macht denselben Fehler, nur die halbe Rechnung zu betrachten, und lässt Serverless teurer erscheinen, als es tatsächlich ist.
Wenn Sie diese Kosten auf Warehouse-Ebene vergleichen möchten, zeigt Ihnen SELECT for Databricks, woher SQL-Warehouse-Ausgaben, Sizing und Auslastung kommen – noch bevor Sie die Konfiguration ändern.
Auto-Stop im SQL Warehouse: UI und API haben unterschiedliche Untergrenzen
Serverless SQL Warehouses bieten mehr Spielraum, Auto-Stop zu verkürzen, als Pro oder Classic SQL Warehouses. In der Databricks-UI liegt das Minimum für Serverless bei fünf Minuten, während API und Declarative Automation Bundles auto_stop_mins bis auf eine Minute reduzieren können. Für Pro und Classic gilt ein Minimum von 10 Minuten.
Die kürzeste Einstellung ist nicht immer die richtige. Ein Auto-Stop von einer Minute kann für isolierte geplante Jobs passen, während interaktive DirectQuery-Workloads davon profitieren können, länger warm zu bleiben. Unsere Empfehlung zum SQL-Warehouse-Auto-Stop liegt bei rund 10 Minuten für die allgemeine SQL-Nutzung.
Mit der Databricks CLI setzen Sie ein Serverless Warehouse auf einen Auto-Stop von einer Minute:
databricks warehouses edit <WAREHOUSE_ID> \ --auto-stop-mins 1Auch die Standardwerte hängen davon ab, wie Sie SQL Warehouses erstellen. Die Databricks-UI setzt für Serverless standardmäßig 10 Minuten und für Pro oder Classic 45 Minuten, während Declarative Automation Bundles 10 Minuten für Serverless und 120 Minuten für Pro oder Classic verwenden. Setzen Sie auto_stop_mins explizit, damit das Deployment nicht vom Standardwert des jeweiligen Konfigurationswegs abhängt.
SQL-Warehouse-Sizing: Größe vs. Clusters
In Databricks SQL lösen Warehouse-Größe und Max Clusters unterschiedliche Performance-Probleme. Die Größe bestimmt die Rechenleistung für einzelne Queries, während Max Clusters steuert, wie viel gleichzeitige Last das Warehouse bedienen kann. Serverless übernimmt mit Intelligent Workload Management zudem einen Teil der Ressourcenzuteilung automatisch.
Nutzen Sie Query- und Queue-Signale, um zu entscheiden, welchen Hebel Sie anpassen:
| Symptom | Passender Stellhebel |
|---|---|
| Eine einzelne Query ist langsam oder lagert stark auf die Festplatte aus | Warehouse-Größe erhöhen |
| Queries verbringen viel Zeit mit Warten auf Kapazität | Max Clusters erhöhen |
| Peak Queued Queries bleibt über null | Warehouse-Größe und Max Clusters prüfen |
| Lange inaktive Phasen zwischen Queries | Auto-Stop verkürzen |
Peak Queued Queries allein identifiziert die genaue Lösung nicht. Ein hoher Wert bei waiting_at_capacity_duration_ms deutet auf Kapazitätsdruck hin, während langsame oder stark auslagernde Queries eher auf die Warehouse-Größe verweisen. Wir empfehlen zu klären, ob der Druck auf Query-Ebene oder auf Concurrency-Ebene entsteht, bevor Sie mehr Compute hinzufügen.
Leerlaufzeit weist auf ein anderes Problem hin. Wenn die Kapazität während der Query-Ausführung ausreicht, das Warehouse aber zwischen Jobs aktiv bleibt, sollten Sie sich die Auto-Stop-Einstellung ansehen.
Wenn Power BI DirectQuery die Serverless-Kostenrechnung verändert
Power BI DirectQuery kann deutlich mehr Warehouse-Aktivität erzeugen, als das Dashboard selbst vermuten lässt, denn jede Interaktion kann eine weitere Query an Databricks senden. Databricks empfiehlt Serverless SQL Warehouses für DirectQuery und LiveQuery, mit einem Auto-Stop-Fenster von 15 bis 30 Minuten für interaktive Workloads.
Wenn das Business nur alle paar Minuten Aktualisierungen benötigt, können Import- oder Hybrid-Modelle die Databricks-SQL-Aktivität reduzieren, indem mehr Report-Interaktionen direkt aus Power BI bedient werden. Materialized Views können wiederkehrende SQL-Arbeit vorab berechnen, auch wenn ihre Aktualisierungen weiterhin separates Serverless Compute nutzen.
Aus unserer Sicht sollte DirectQuery einer der ersten Punkte sein, die Sie untersuchen, wenn die Serverless-Kosten nicht zur Komplexität der Dashboards passen. Prüfen Sie, ob der BI-Verbindungsmodus mehr Aktivität erzeugt, als die geforderte Aktualität tatsächlich erfordert – bevor Sie dem Serverless-Preismodell die Schuld geben.
Von einzelnen Anpassungen zur laufenden Praxis
Wer die SQL-Warehouse-Kosten im Griff behalten will, braucht kontinuierliche Transparenz über Sizing, Leerlaufzeiten und Kapazitätsdruck. Unsere SQL-Warehouse-Kostenansicht führt diese Signale zusammen, damit Sie sehen, wo sich ein zweiter Blick auf die Konfiguration lohnt.
Unsere Automated Savings können unterstützte Worker-Count- und Autoscaling-Einstellungen für SQL Warehouses an die jeweilige Last anpassen. Auto-Stop bleibt ein separater Hebel: Prüfen Sie auto_stop_mins nach Deployments weiterhin und auditieren Sie die BI-Verbindungsmodi, wenn die Aktivität nicht mehr zur geforderten Aktualität passt.
Die nächste Stufe der Einsparungen besteht darin, diese Checks zur festen Routine zu machen. Die Frage ist, ob die manuelle Prüfung von Größe, Max Clusters, Auto-Stop und BI-Modi noch ein vertretbarer Kompromiss ist – oder ob sich diese wiederkehrende Arbeit allmählich summiert.
Kosten des Databricks Serverless SQL Warehouse: Was Sie zuerst anpassen sollten
Ordnen Sie die Einstellung dem Signal zu, das Sie beobachten: Leerlauffenster deuten auf Auto-Stop hin, Queue-Druck auf Kapazität, langsame Einzel-Queries auf die Warehouse-Größe und unerwartete BI-Aktivität auf den Verbindungsmodus. Vergleichen Sie Serverless, Pro und Classic anhand der Gesamtkosten statt nur des DBU-Preises.
Prüfen Sie die Faktenlage, bevor Sie die Konfiguration ändern. Unsere Databricks-Kostenansicht führt SQL-Warehouse-Kosten, Sizing, ungenutzte Compute-Kapazität und Auslastung zusammen, damit Sie sehen, welche Einstellung zuerst Aufmerksamkeit verdient.