Databricks Serverless: Wann das Compute-Modell sinnvoll ist und wann Classic besser bleibt
Die Kernaussagen auf einen Blick.
- Databricks Serverless führt SQL Warehouses, Jobs, Notebooks, Model Serving und Lakeflow Pipelines auf vollständig von Databricks verwaltetem Compute aus. Cluster-Provisionierung, Startzeiten und ein Teil des Betriebsaufwands entfallen.
- Der Vorteil entsteht vor allem bei interaktiven, kurzen oder schwankend genutzten Workloads. Dem stehen höhere aktive DBU-Raten, weniger Konfigurationsmöglichkeiten und unterschiedliche Verfügbarkeit je Cloud und Region gegenüber.
- Vor einer Plattform-Entscheidung braucht es eine Workload-Inventur: Laufzeit, Idle-Anteil, Datenvolumen, Konfigurationsbedarf, Region, Governance und heutige Classic-Kosten müssen je Workload-Klasse bewertet werden.
- Aus TCO-Sicht bewegt Serverless drei Hebel gleichzeitig: weniger FTE-Aufwand für Cluster-Betrieb, weniger Leerlauf- und Wartekosten und schnellere Time-to-Value für neue SQL-, Genie-, Notebook- und Serving-Workloads.
- Mein Vorschlag: Serverless zuerst für SQL Warehouses, Genie, interaktive Notebooks, kurze Jobs und schwankend genutztes Model Serving prüfen. Lange Batch-Workloads, stateful Streaming und stark angepasster Compute bleiben häufig besser auf Classic.
Inhaltsverzeichnis
Serverless ist nicht automatisch günstiger
Die Databricks-Rechnung steigt, seit der erste Serverless-SQL-Endpoint aktiviert wurde. Ob der höhere Verbrauch durch geringere Laufzeiten und weniger Betriebsaufwand ausgeglichen wird, ist zunächst unklar. Die Self-Service-Abfragen sind schneller, Genie funktioniert, die Notebook-Sessions starten in Sekunden. Gleichzeitig fragt das FinOps- oder Controlling-Team, warum die Kosten für einen vergleichbaren BI-Workload gestiegen sind.
In wachsenden Databricks-Plattformen wird Serverless häufig schrittweise und ohne übergreifende Entscheidung eingeführt. Für einen Genie-Piloten wurde ein Serverless SQL Warehouse eingerichtet, Notebook-Nutzer haben Serverless Compute aktiviert, um lange Startzeiten klassischer Cluster zu vermeiden, und nach und nach kommen Jobs, Model-Serving-Endpunkte und Lakeflow-Pipelines hinzu. So entsteht eine gemischte Compute-Landschaft, ohne dass ihre Auswahlkriterien verbindlich dokumentiert wurden.
Welche Workloads gehören jetzt eigentlich auf Serverless, welche auf Classic? Wie entwickeln sich Kosten und Laufzeiten je Workload-Klasse? Welche Konfigurationsmöglichkeiten entfallen und für welche Workloads ist das relevant? Welche Serverless-Funktionen stehen in den benötigten Clouds und Regionen zur Verfügung?
Serverless verlagert Compute-Betrieb zu Databricks und verändert damit Kostenmodell, Netzwerkarchitektur und Konfigurationsmöglichkeiten. Die Entscheidung sollte deshalb je Workload getroffen werden.
Was ist Databricks Serverless?
Serverless bei Databricks ist ein Compute-Modell, in dem die Rechenleistung im Databricks-eigenen Backend läuft. Der Compute wird nicht mehr als klassischer Cluster im Cloud-Account des Kunden bereitgestellt und betrieben; Databricks stellt von Databricks vorgehaltene Compute-Kapazitäten bereit, die kurze Startzeiten und automatische Skalierung ermöglichen. Abgerechnet wird ausschließlich in DBUs, die zugrunde liegenden Infrastrukturkosten werden nicht mehr separat über den Cloud-Account des Kunden abgerechnet. Photon ist in den entsprechenden Serverless-Ausprägungen fest integriert.
Serverless ist damit kein lediglich schneller startender Classic-Cluster, sondern ein anderes Betriebs- und Abrechnungsmodell. Microsoft Learn beschreibt Serverless Compute als von Azure Databricks verwalteten Dienst für Notebooks, Workflows und Lakeflow Spark Declarative Pipelines mit On-Demand-Compute. Auf AWS und GCP gilt dieselbe Mechanik. Das Modell existiert in mehreren Ausprägungen: Serverless SQL Warehouses für BI-Workloads, Serverless Compute für Jobs und Notebooks, Serverless Model Serving für ML- und LLM-Endpoints sowie Serverless Pipelines für Lakeflow Declarative Pipelines. Allen Varianten gemeinsam ist der vollständig verwaltete Compute-Betrieb. Funktionsumfang, regionale Verfügbarkeit und Kostenmodell unterscheiden sich jedoch je Workload-Typ.
Der wesentliche Unterschied besteht darin, dass Databricks wesentliche Entscheidungen zu Skalierung, Laufzeit und Infrastruktur übernimmt. Die Konsequenz für Architektur und Betrieb ist konkret: Bestehende Cluster-Policies lassen sich nur eingeschränkt auf Serverless übertragen, und private Netzwerkanbindungen werden über eigene Serverless-spezifische Konfigurationen eingerichtet. Wie diese Compute-Schicht in die größere Plattform-Architektur passt und welche Rolle sie neben Unity Catalog, Photon und DatabricksIQ spielt, ordnen wir in der Databricks Data Intelligence Platform ein.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
SQL Warehouses, Jobs, Notebooks, Model Serving und Pipelines
Databricks bietet Serverless für mehrere unterschiedliche Workload-Klassen an. Jede Variante unterscheidet sich bei Funktionsumfang, Verfügbarkeit, Abrechnung und typischem Einsatzgebiet. Entscheidend ist nicht eine plattformweite Ja-oder-Nein-Entscheidung. Stattdessen sollte je Workload entschieden werden, welche Serverless-Variante sinnvoll ist.
| Serverless-Familie | Start-Latenz | Typische Einsatzbereiche | Produktstatus und Verfügbarkeit | Abrechnungsmodell |
|---|---|---|---|---|
| Serverless SQL Warehouses | < 6 Sek | BI-Dashboards, Self-Service-SQL, Genie, AI/BI | Allgemein verfügbar und für Genie erforderlich | Höhere DBU-Rate als bei klassischen Varianten, dafür keine separate VM-Abrechnung |
| Serverless Compute für Jobs und Notebooks | < 30 Sek | kurze Jobs, Notebook-Exploration, Lakeflow-Aufgaben | GA, regional unterschiedlich | DBU-Aufpreis gegen Classic-Job-Compute |
| Serverless Model Serving | Sekunden | Skalierbare Endpunkte für ML- und GenAI-Modelle, Mosaic AI | GA für die meisten Regionen | DBU pro Endpoint-Stunde, Scale-to-Zero möglich |
| Serverless Lakeflow Declarative Pipelines | < 30 Sek | Lakeflow-Pipelines im Serverless-Modus | GA, regional unterschiedlich | DBU pro Pipeline-Stunde, Workload-spezifische Abrechnung |
| Serverless für AI Functions | Sekunden | , AI-Functions in SQL | GA innerhalb Serverless-SQL | im SQL-Warehouse-DBU enthalten |
Die Übersicht zeigt das Spektrum, in dem Serverless heute angeboten wird. Wie die einzelnen Compute-Familien in der Plattform-Praxis funktionieren, welche Voraussetzungen sie mitbringen und wo ihre wirtschaftlichen Stärken liegen, vertiefen wir weiter unten je Compute-Modell. Davor lohnt der direkte Vergleich mit Classic, die Kostenfrage und die TCO-Sicht.
Unterschiede bei Betrieb, Kontrolle und Kosten
Der zentrale Unterschied liegt darin, wer den Compute bereitstellt, konfiguriert und skaliert. Bei Classic provisioniert Databricks Cloud-VMs in der Subscription des Kunden; der Cluster startet, läuft, skaliert und endet nach den Cluster-Policies des Workspaces. Bei Serverless wird diese Ebene vollständig von Databricks betrieben.
Das hat auch direkten Einfluss auf die Abrechnung. Bei Classic laufen die Kosten zweigeteilt: DBUs gehen über Databricks, die zugrunde liegenden VMs erscheinen als separater Posten auf der Cloud-Rechnung. Bei Serverless läuft alles als Gesamtkostensatz direkt über Databricks. Die Cloud-VM-Rechnung entfällt, dafür liegt die DBU-Rate höher.
| Achse | Classic-Compute | Serverless-Compute |
|---|---|---|
| Cluster-Provisionierung | Kunden-VPC / Subscription | Databricks-Backend |
| Compute-Größe | Cluster-Policy, manuell | Automatisch durch Databricks gesteuert |
| Start-Latenz | 3–8 Min | < 30 Sek |
| Idle-Verhalten | bezahlt bis zum Auto-Termination | Abrechnung entsprechend der serverless-spezifischen aktiven Nutzung |
| Photon | optional, per Policy | Default, nicht abschaltbar |
| Abrechnung | DBU + Cloud-VM-Rechnung | nur DBU (höherer Multiplikator) |
| Spot-Instances | nutzbar | nicht steuerbar |
| Init-Scripts, Custom-Images | unterstützt | Nur begrenzt oder über alternative Mechanismen verfügbar |
| Private Link / Netzwerk | über Workspace-VPC | eigener Konfigurations-Pfad |
| Tagging / FinOps | Cluster-Tags | Tagging und Budgets über Workload-, Warehouse- und Workspace-Konfiguration |
Für Plattformteams bedeutet Serverless vor allem weniger direkte Kontrolle über die Compute-Konfiguration. Eine Spark-Pipeline mit gezieltem Memory-Footprint und Spot-Instances kann nicht unverändert auf Serverless übertragen werden; Init-Scripts für Custom-Libraries oder spezielle Treiber brauchen einen anderen Weg. Dafür reduzieren sich Startzeiten und viele durch Leerlauf verursachte Kosten, die je nach Nutzung einen relevanten Anteil der Kosten verursachen können.
Im Plattform-Alltag bedeutet das eine andere Trennlinie. Classic bleibt sinnvoll für Workloads, wenn Kosten und Performance wesentlich von Instanzwahl, Spot-Nutzung oder spezifischem Tuning abhängen. Serverless eignet sich besonders für Workloads, wenn kurze Startzeiten, geringe Leerlaufkosten und automatische Skalierung entscheidend sind.
Was kostet Databricks Serverless?
Serverless verwendet in der Regel höhere DBU-Raten als vergleichbare Classic-Workloads. Dem stehen der Wegfall einer separaten VM-Abrechnung und geringere Leerlaufzeiten gegenüber. Ob Serverless wirtschaftlicher ist, hängt deshalb vom konkreten Auslastungsprofil ab. Databricks führt die Serverless-DBU-Multiplikatoren pro Workload-Familie und Cloud separat aus; aktuelle Werte gehören auf die Pricing-Seite der eigenen Cloud zum Zeitpunkt der Entscheidung. Für die Bewertung sollten Gesamtkosten, Laufzeit und Betriebsaufwand pro Workload verglichen werden.
Drei Posten ändern sich, wenn ein Workload von Classic auf Serverless umzieht:
- Cluster-Start-Wartezeit fällt weg. Bei fünf Minuten Start je Lauf und vier Läufen pro Tag sind das 20 Minuten täglich pro Pipeline, die nicht mehr berechnet werden. Dieser Effekt ist insbesondere bei kurzen und häufig ausgeführten Jobs relevant.
- Idle-Zeit fällt weg. Bei Notebook-Cluster, die täglich sechs Stunden „on“ stehen, aber nur zwei aktiv arbeiten, entstehen auf Classic Kosten für mehrere Stunden geringer oder fehlender Nutzung. Serverless rechnet nur die aktive Zeit ab.
- DBU-Multiplikator steigt. Je Workload und Cloud kann die DBU-Rate deutlich über der Classic-Variante liegen. Bei dauerhaft ausgelasteten Workloads kann dieser Aufpreis die Einsparungen durch geringere Leerlaufzeiten übersteigen.
Bei Serverless Compute für Jobs und Notebooks lässt sich der Aufpreis zusätzlich über die Wahl des Performance-Modus steuern: Standard ist je nach Cloud bis zu 70 Prozent günstiger als Performance-optimized. Die Modus-Wahl wird im Abschnitt zu Serverless Compute für Jobs und Notebooks weiter unten vertieft.
| Workload-Profil | Effekt von Serverless | FinOps-Folge |
|---|---|---|
| BI-Workload, Genie, Self-Service-SQL | Start- und Leerlaufeffekte können überwiegen | Kann wirtschaftlicher sein |
| Notebook-Exploration mit hoher Idle-Zeit | Start- und Leerlaufeffekte können überwiegen | Kann wirtschaftlicher sein |
| Kurze, häufige Jobs (< 15 Min) | Start- und Idle-Posten fallen weg | Kann wirtschaftlicher sein |
| Lang laufende, voll ausgelastete Batch-Jobs | Die höhere aktive DBU-Rate kann überwiegen | Kann höhere Gesamtkosten verursachen |
| Specialty-Compute mit Spot-Instances | kein Spot-Hebel auf Serverless | Kann höhere Gesamtkosten verursachen |
| Model Serving mit häufigem Lastwechsel | Scale-to-Zero kann bei schwankender Nutzung Kosten reduzieren | Kann wirtschaftlicher sein |
Die Konsequenz für die Plattform-Steuerung: Eine pauschale Umstellung kann bei ungeeigneten Workloads unnötige Mehrkosten verursachen. Ein grundsätzlicher Verzicht lässt mögliche Vorteile bei interaktiven und kurz laufenden Workloads ungenutzt. Die Bewertung sollte deshalb je Workload erfolgen.
Ein häufiges Problem bei der Kostenanalyse ist die fehlende Tagging-Trennung zwischen Genie-Nutzung und sonstigen BI-Abfragen auf demselben Serverless SQL Warehouse. Wenn ein Endpoint gleichzeitig Dashboards, das Genie-Pilot-Team und Notebook-Nutzer bedient, lässt sich ein Kostenanstieg nicht eindeutig dem jeweiligen Nutzungszweck zuordnen. Für relevante Piloten sollten mindestens separate Warehouses, Budgets und Tags vorgesehen werden.
FTE-Aufwand, Time-to-Value und FinOps
Die DBU-Rate ist nur ein Posten in der Gesamtkostenrechnung. Aus der Plattform-Steuerung gehören drei weitere Dimensionen daneben, die in der reinen Compute-Diskussion regelmäßig untergehen: Personalaufwand für Cluster-Betrieb, Opportunitätskosten verlorener Stunden durch Start- und Idle-Zeiten und Time-to-Value für neue Workloads. Bei Classic verteilt sich der TCO auf drei Kostenblöcke (DBU, Infrastruktur, operative Kosten); bei Serverless konsolidiert sich alles in eine einzige DBU-Position, und die verbleibende Differenz ist die rechnerische TCO-Ersparnis.
Bei Serverless wird sekundengenau auf Basis der tatsächlichen Nutzung abgerechnet. Es fallen nur DBU-Kosten an, solange ein Job, eine SQL-Abfrage oder ein Notebook aktiv ausgeführt wird; Leerlaufzeiten zwischen Aktivitäten verursachen keine Gebühren, weil die Compute-Ressourcen nicht reserviert bleiben. Bei interaktiven oder unregelmäßig genutzten Workloads bringt das den unmittelbaren Kostenvorteil.
Bei Classic ist die Rechnung zweigeteilt. DBU-Kosten gehen über Databricks, die zugrunde liegenden virtuellen Maschinen erscheinen separat im Hyperscaler-Konto (Azure, AWS oder GCP). Klassische All-Purpose-Cluster laufen häufig über längere Zeiträume und verursachen Compute- und Storage-Kosten auch in Leerlauf-Phasen, weil Auto-Termination zwar konfiguriert werden kann, aber nicht automatisch greift. Ein ehrlicher Vergleich muss deshalb die VM-Stundenrate im Hyperscaler-Konto, die DBU-Rate und den FTE-Aufwand für Cluster-Pflege (Policies, Tagging, Auto-Termination, Spot-Konfiguration) zusammen betrachten. Sonst sieht das DBU-Delta auf den ersten Blick nach reiner Mehrausgabe aus.
Wo der TCO sinkt. Drei Punkte sind direkt sichtbar. Ein Teil der Cluster-Arbeit fällt weg: Policies, Spot-Konfigurationen, Auto-Termination, Cluster-Probleme. Interaktive Workloads werden günstiger, weil Startzeiten kurz sind und Idle-Zeit nicht mehr abgerechnet wird; bei Self-Service-SQL, Genie und Notebook-Exploration zeigt sich das sofort. Und neue Anwendungsfälle gehen schneller in Betrieb: ein Genie-Pilot, ein neues Dashboard oder ein Serving-Endpoint startet ohne Cluster-Provisionierung und Sizing-Diskussion.
Wo der TCO steigt. Bei dauerhaft ausgelasteten Workloads kann die höhere DBU-Rate teurer werden, als an FTE-Aufwand eingespart wird. Das Tagging muss neu aufgesetzt werden, weil Cluster-Tags wegfallen. Und am Anfang kommen einmalige Kosten dazu: Libraries müssen anders gepflegt werden, Init-Scripts brauchen einen Ersatz, der Performance-Modus muss bewusst gewählt sein. Diese Posten gehören in die Rechnung, sonst sieht das DBU-Delta nach reiner Mehrausgabe aus.
Wie der Business Case rechnet. Pro Workload, nicht pauschal für die ganze Plattform. Ein ehrlicher Vorher-Nachher-Vergleich braucht Compute-Kosten, FTE-Anteil und Idle-Anteil über einen festen Zeitraum. SQL und kurze interaktive Workloads kommen meistens günstiger heraus, lange Batch-Jobs meistens nicht. Wichtig ist außerdem der Rollback-Pfad über Asset Bundles oder Terraform. Er ist die Absicherung gegen Fehl-Migrationen.
Serverless ist damit keine pauschale Kosten-Reduktion und keine pauschale Mehrkosten-Falle. Es ist eine Compute-Wahl mit je Workload eigenen TCO-Konsequenzen, sinnvoll bewertbar nur mit Workload-Inventur, sauberem Tagging und einem messbaren Vergleichszeitraum.
Welche Workloads auf Serverless, welche auf Classic?
Die Compute-Wahl ist eine Workload-Entscheidung, keine Plattform-Entscheidung. Den Ausschlag geben vier Achsen: Latenz-Profil, Häufigkeit, Last-Volatilität und Konfigurations-Bedarf.
| Achse | Serverless ist sinnvoll, wenn … | Classic bleibt sinnvoll, wenn … |
|---|---|---|
| Latenz-Profil | Antwort in Sekunden bis < 1 Min nötig | Laufzeit ist planbar und nicht interaktiv |
| Häufigkeit | viele kurze Läufe pro Tag | wenige lange Läufe, geplante Nachtfenster |
| Last-Volatilität | Stark schwankende oder unregelmäßige Auslastung | Last konstant, gut planbar |
| Datenvolumen | klein bis mittel pro Lauf | Lang laufende oder datenintensive Batch-Verarbeitung |
| Konfigurations-Bedarf | Keine speziellen Anforderungen an Instanztyp oder Runtime-Konfiguration | Custom-Libraries, spezielle JVM-Args, Spot |
| Region-Verfügbarkeit | Serverless ist in der Cloud-Region GA | Benötigte Serverless-Funktion ist regional nicht verfügbar |
| Daten-Ausgangslage | Daten im Lakehouse, Unity Catalog aktiv | Workloads außerhalb Unity Catalog |
Typische Serverless-Kandidaten
Self-Service-SQL und Dashboards, Genie- und AI/BI-Workloads, Notebook-Exploration mit hoher Idle-Zeit, kurze ETL-Jobs unter 15 Minuten, Model-Serving-Endpoints mit schwankendem Traffic. Kurze Startzeiten und geringere Leerlaufkosten bieten hier einen wesentlichen Vorteil.
Typische Classic-Kandidaten
Lange Batch-Pipelines über große Delta-Tabellen mit voller CPU-Auslastung, Workloads mit Spot- oder Reserved-Instances, Pipelines mit Custom-Libraries oder Init-Scripts, stateful Streaming, regulierte Workloads ohne Serverless-GA-Status. Sie profitieren nur begrenzt von kurzen Startzeiten.
Workloads mit offenem Ergebnis
Mittlere Jobs zwischen 15 und 60 Minuten, regelmäßige Pipelines mit moderater Auslastung, kleinere Streaming-Aufgaben. Für diese Workloads ist ein direkter Kosten- und Laufzeitvergleich erforderlich.
Der pragmatische Einstieg ist eine Workload-Inventur: welche Pipelines, welche SQL-Warehouses, welche Notebook-Cluster laufen heute, mit welcher Laufzeit, welchem Idle-Anteil, welchem Datenvolumen, in welcher Cloud-Region. Erst auf dieser Inventur entstehen Serverless-Kandidaten.
BI, Genie und Self-Service-SQL
SQL Warehouses sind die am längsten etablierte Serverless-Variante und tragen heute die meisten BI-, Dashboard- und Self-Service-Szenarien auf Databricks. Startzeiten liegen unter sechs Sekunden, Photon ist Default, Predictive I/O und Result-Caching sind aktiv. Damit eignen sich Serverless SQL Warehouses besonders für interaktive Abfragen, in denen Antwortzeit und konsistente Performance über den Nutzungswert entscheiden.
Für Genie und AI/BI ist ein Serverless SQL Warehouse Pflicht. Die Pro-Variante steht für Genie nicht zur Verfügung. Plattformen, die einen Genie-Piloten oder eine AI/BI-Dashboard-Strategie planen, kommen am Serverless SQL Warehouse nicht vorbei. Voraussetzungen, Aktivierung und Governance-Pfad sind im Genie-Companion-Space zusammengefasst.
Der typische FinOps-Stolperstein liegt in der Tagging-Trennung. Wenn ein Endpoint gleichzeitig Dashboards, Self-Service-Nutzer und einen Genie-Piloten bedient, lässt sich der Kostenanstieg nicht eindeutig zuordnen. Für jeden ersten Genie-, AI/BI- oder neuen Self-Service-Use-Case sollten daher mindestens separates Warehouse, Budget und Tagging stehen. Sonst läuft die TCO-Bewertung in eine Sammelrechnung ohne Steuerungsgriff.
Serverless Compute für Jobs und Notebooks: kurze Jobs und Exploration
Serverless Compute für Jobs und Notebooks adressiert zwei häufige Nachteile klassischer Cluster: den Cluster-Start, der bei Classic je nach Cloud zwischen drei und acht Minuten dauert, und Leerlaufzeiten interaktiver Cluster, die weiterhin Kosten verursachen. Auf Serverless startet die Compute-Schicht in unter einer Minute, in Lastpausen wird sie heruntergefahren.
Innerhalb dieser Familie gibt es zwei Performance-Modi. Performance-optimized startet in unter einer Minute und ist auf interaktive und latenzkritische Workloads ausgerichtet. Standard hat Startzeiten im Bereich klassischer Cluster, kostet aber je nach Cloud bis zu 70 Prozent weniger als Performance-optimized. Für planbare Hintergrund-Jobs ist Standard häufig die günstigere Wahl, für Notebook-Exploration und kurze On-Demand-Läufe Performance-optimized.
Typische Einsatzfelder sind kurze ETL-Jobs unter 15 Minuten, Notebook-Sessions mit hoher Idle-Zeit, Self-Service-Analysen und Lakeflow-Aufgaben mit moderaten Datenmengen. Dafür stehen weniger Möglichkeiten für Instanzwahl, Spot-Nutzung, Init-Scripts und tiefes Spark-Tuning zur Verfügung. Workloads, deren Kosten oder Performance wesentlich von genau diesen Hebeln abhängen, bleiben besser auf Classic.
Serverless Model Serving und Lakeflow Pipelines
Serverless Model Serving hostet ML- und LLM-Endpoints im Databricks-Backend. Der Endpoint skaliert je nach Traffic und geht in Lastpausen auf Null. Für viele ML- und GenAI-Endpunkte ist das die naheliegende Betriebsform.
Serverless Pipelines für Lakeflow Declarative Pipelines (das ehemalige Delta Live Tables) sind eine vergleichsweise neue Serverless-Variante und reduzieren den Aufwand für Compute-Konfiguration und Skalierung von Pipelines. Standardisierte kleine und mittlere Pipelines profitieren davon am stärksten. Bei spezialisierten Streaming-Mustern und sehr großen Batch-Pipelines kann Classic weiterhin die besser kontrollierbare oder wirtschaftlichere Variante sein.
Eine eigene Rolle spielt Lakeflow Connect für die Ingestion. Lakeflow Connect wird ausschließlich auf Serverless angeboten; einen Classic-Pfad gibt es nicht. Plattformen, die Ingestion über Lakeflow Connect planen, übernehmen damit zwangsläufig Serverless als Betriebsmodell für diese Pipelines.
Unity Catalog, Private Link und Tagging
Bei Serverless läuft der Compute außerhalb der vom Kunden betriebenen Workspace-Netzwerkebene. Das verändert die Netzwerk-Architektur, Datenhaltung und Unity-Catalog-Berechtigungen bleiben davon grundsätzlich getrennt. Die Daten verbleiben weiterhin im konfigurierten Cloud-Speicher des Kunden (S3, ADLS, GCS), Unity Catalog regelt weiterhin, wer welche Objekte sehen darf, und Serverless-Aktivitäten können über die regulären Audit- und Systemtabellen ausgewertet werden.
Serverless setzt für die relevanten Workloads eine Unity-Catalog-basierte Daten- und Berechtigungsstruktur voraus. Daten-Zugriff läuft weiter über Catalog-, Schema- und Tabellen-Berechtigungen, Row Filter und Column Masks gelten auch im Serverless-Pfad. Wie das Berechtigungsmodell sauber gepflegt wird und welche Strukturentscheidungen vor dem Rollout stehen, gehört in den Überblick zu Unity Catalog.
Die Netzwerkanbindung unterscheidet sich jedoch deutlich vom Classic-Modell. Serverless-Workloads benötigen eine serverless-spezifische Verbindung zu Cloud-Speicher und privaten Systemen. Databricks bietet Private Link für Serverless, aktiviert wird er pro Workload-Familie und Cloud separat. Die Konfiguration läuft über einen eigenen Serverless-Private-Endpoint, der pro Region und Cloud existieren muss. In regulierten Umgebungen muss diese Anbindung vor dem produktiven Einsatz gemeinsam mit Netzwerk-, Security- und Cloud-Teams geplant werden.
Workload-Inventur, Pilot und Rollback
Die Umstellung sollte schrittweise nach Workload-Klassen erfolgen. Zuerst sollten Workloads mit hohem Leerlaufanteil und geringen technischen Sonderanforderungen migriert werden. Stark angepasste oder besonders rechenintensive Workloads sollten erst später bewertet werden. Vier Phasen tragen das Vorgehen.
Workload-Inventur als Entscheidungsgrundlage
Welche SQL Warehouses, Jobs, Notebooks und Pipelines laufen heute, mit welcher Laufzeit, welchem Idle-Anteil und welcher Konfiguration? Aus dieser Inventur entstehen drei Listen: Serverless-Kandidaten, Classic-Kandidaten, Graubereich-Kandidaten. Ohne belastbare Nutzungsdaten bleibt die Einordnung weitgehend subjektiv.
Serverless für SQL aktivieren
Serverless SQL Warehouses sind ein häufig geeigneter Einstieg. Genie-Workloads, Self-Service-SQL und Dashboards lassen sich meist mit geringem Anpassungsaufwand umstellen. Tagging über Workspace-Settings einrichten, Budgets pro Warehouse setzen, Kosten und Nutzerverhalten über einen definierten Vergleichszeitraum messen.
Kurze Jobs und Notebook-Compute umstellen
Job-Bundles unter 15 Minuten und Notebook-Cluster mit hoher Idle-Zeit anschließend prüfen. Hier werden häufig Einschränkungen bei Bibliotheken, Init-Scripts und Spark-Konfigurationen sichtbar. Als Lakeflow-Bundles deployte Jobs lassen sich meist leichter über eine konfigurierbare Compute-Option migrieren.
Model Serving und Pipelines bewerten
Model-Serving-Endpoints anhand ihres Traffic-, Skalierungs- und Kostenprofils separat bewerten. Lakeflow-Pipelines auf Serverless eignen sich oft für standardisierte kleine und mittlere Pipelines. Lange Batch-Pipelines, Pipelines mit Spot-Instances oder spezialisierten Treibern bleiben bewusst auf Classic.
Grenzen von Databricks Serverless
Weniger Compute- und Runtime-Konfiguration
Optimierung über Spark-Configs, Custom-Libraries, Init-Scripts oder Spot-Instances ist im Serverless-Modell nur eingeschränkt oder über andere Mechanismen möglich. Für spezialisierte oder stark optimierte Workloads mit Performance-Tuning bleibt Classic die richtige Wahl.
Andere Kostensteuerung nötig
Ohne sauberes Tagging über Workspace-Settings, getrennte Warehouses pro Pilotteam und ein quartalsweises Workload-Profil lässt sich der zusätzliche Verbrauch nicht zuverlässig einzelnen Teams und Anwendungen zuordnen. Gemeinsam genutzte SQL Warehouses für Genie, Dashboards und Ad-hoc-Abfragen sind dabei besonders schwer sauber aufzuteilen.
Stateful Streaming und lange Batches bleiben Classic
Wo das Workload-Profil viele Stunden voll ausgelastet läuft oder spezielle Maintenance- und Tuning-Operationen braucht, kann die höhere aktive DBU-Rate die Vorteile kürzerer Start- und Leerlaufzeiten übersteigen. Diese Workloads gehören nicht auf Serverless.
Kein Ersatz für Architektur und Governance
Ohne saubere Datenprodukte, eine klare Bronze-/Silver-/Gold-Schicht und ein Unity-Catalog-Modell beschleunigt Serverless lediglich Workloads auf einer weiterhin ungeklärten Daten- und Governance-Struktur. Architektur und Governance kommen vor der Compute-Wahl.
Serverless ist ein starkes Werkzeug für die richtigen Workloads. Die zugrunde liegenden Architektur- und Governance-Entscheidungen bleiben weiterhin erforderlich, und es ist nicht für jede Region und jede Last gleich weit.
Fazit
Databricks Serverless ist besonders sinnvoll, wenn lange Startzeiten, hohe Leerlaufanteile und stark schwankende interaktive Nutzung den Betrieb klassischer Cluster unwirtschaftlich machen.
Voraussetzung ist die Verfügbarkeit der benötigten Funktionen in der jeweiligen Cloud und Region. Typische Einsatzfelder sind Genie, AI/BI, Self-Service-SQL, interaktive Notebooks und schwankend genutzte Serving-Endpunkte.
Typische Hinweise auf geeignete Serverless-Workloads sind:
- SQL Warehouses, die für Genie aktiviert wurden und deren Kosten nicht eindeutig nach Nutzung und Konsumentengruppe aufgeschlüsselt werden können
- Notebook-Cluster, die im Tagesschnitt überwiegend im Leerlauf laufen
- Kurze ETL-Jobs unter 15 Minuten, die einen relevanten Anteil ihrer Gesamtlaufzeit mit der Clusterbereitstellung verbringen
- Model-Serving-Anwendungen mit stark schwankendem oder sporadischem Traffic
- Plattformen vor einem Genie- oder AI/BI-Rollout, in denen manuelle Compute-Bereitstellung die Einführung neuer Anwendungen verlangsamt
Wer diese Symptome nicht hat, eine stabile Batch-Last über große Delta-Tabellen fährt, mit Spot-Instances optimiert oder in einer Region ohne Serverless-Reife sitzt, sollte Serverless nicht allein aus Gründen der Standardisierung priorisieren. Dann liegen die größeren Optimierungsmöglichkeiten möglicherweise in Code, Datenmodell, Orchestrierung oder Kapazitätsplanung.
Serverless eignet sich vor allem für Workloads, bei denen Startzeit, Leerlauf und schwankende Last die Kosten bestimmen. Für dauerhaft ausgelastete oder speziell konfigurierte Workloads bleibt Classic häufig die bessere Ausgangsbasis.
Ziel sollte keine pauschale Standardisierung auf eine Compute-Variante sein. Ziel ist eine nachvollziehbare Zuordnung der Workloads, deren Kosten und Laufzeiten regelmäßig überprüft werden können.
Zunächst Laufzeit, Auslastung, Idle-Anteil, Datenvolumen und Konfigurationsbedarf der Workloads erfassen, Serverless zuerst für SQL und kurze Jobs aktivieren, lange, vollständig ausgelastete und stark angepasste Workloads bewusst auf Classic belassen und Kosten und Laufzeiten je Workload-Klasse regelmäßig mit der bisherigen Classic-Konfiguration vergleichen.
Lohnt sich Serverless für eure Plattform wirklich?
- welche eurer Workloads echte Kandidaten für Serverless sind
- welche Governance-, FinOps- und Region-Risiken vor dem nächsten Ausbau geprüft werden müssen
- welcher Migrationspfad pro Workload-Familie trägt und welcher Roll-back-Pfad daneben steht
FAQ
Serverless bei Databricks ist ein Compute-Modell, in dem die Rechenleistung im Databricks-eigenen Backend läuft statt im VPC des Kunden. Es existiert für SQL Warehouses, Jobs und Notebooks, Model Serving und Lakeflow Pipelines. Cluster-Verwaltung entfällt, abgerechnet wird ausschließlich in DBUs, Photon ist standardmäßig aktiv.
![Mitarbeiter am Schreibtisch vor zwei Monitoren, überlagert von einer Karte 'Policy: pii' mit einer Tabelle, die dieselbe Kartenzahlungs-Spalte je nach Rolle unterschiedlich zeigt: Finance sieht VISA •••• 4417, Data Eng sieht [REDACTED], Analyst sieht einen Hash-Wert, sowie einem Badge 'Tag: pii · Policy aktiv'](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fajsqxuma%2Fproduction%2F0127d64d384ec70b3186a60fe880484d6d5d393a-1376x768.avif%3Fw%3D1920%26fit%3Dmax%26auto%3Dformat%26q%3D75&w=3840&q=75)