Databricks vs. Snowflake: Ein ehrlicher Vergleich für 2024

Ursprünglich starteten Databricks und Snowflake als Partner, jeweils mit Fokus auf unterschiedliche Aspekte des Datenmanagements. Snowflake spezialisierte sich auf Data Warehousing, während sich Databricks seine Nische im Managed Spark suchte und schnell in Machine-Learning-(ML)-Workloads expandierte. Interessanterweise empfahlen sie sich damals sogar gegenseitig Kunden weiter.

Heute, viele Jahre später, haben beide Plattformen eine bemerkenswerte Entwicklung hinter sich. Ein Blick auf die Websites (Stand: 27. Februar 2024) zeigt: Snowflake bezeichnet sich heute als "data cloud", Databricks positioniert sich als "data intelligence platform":

Am Ende sind beide umfassende All-in-One-Data-Cloud-Plattformen, die eine Vielzahl unterschiedlicher Daten-Use-Cases bedienen.

Trotzdem lohnt sich ein Blick auf ihre Entstehungsgeschichten – sie erklären die jeweiligen Stärken und Schwächen bis heute.

Snowflake wurde 2012 von Data-Warehousing-Experten gegründet, die zuvor bei Oracle und beim Data-Warehousing-Unternehmen VectorWise tätig waren. 2014 – also vor 10 Jahren – kam Snowflake mit seinem zentralen Data-Warehousing-Produkt auf den Markt, das oft als "elastic data warehouse" bezeichnet wurde. Grund war die einzigartige Architektur, die Compute und Storage unabhängig voneinander skalieren konnte.

Kurz nach dem Snowflake-Launch brachte Databricks sein erstes Produkt heraus – in einem völlig anderen Bereich. Gegründet wurde Databricks von den Erfindern von Apache Spark, allesamt Akademiker aus dem High-Performance-Computing-Bereich in Berkeley. Ihr erstes Produkt war ein Managed Offering für Apache Spark inklusive Notebook-Oberfläche, um Jobs interaktiv in den Compute-Clustern auszuführen.

Snowflake führte 2017 Data-Sharing-Funktionalität ein und legte 2019 mit einem Marketplace nach, auf dem Kunden Datasets voneinander beziehen konnten.

Im gleichen Zeitraum ging Databricks tiefer in den ML-Bereich – 2019 mit dem Launch des Managed-MLflow-Angebots, 2020 mit MLflow Model Serving.

Spannend ist, wie beide Unternehmen auf Marktanforderungen reagiert und konkurrierende Funktionen nachgezogen haben.

Snowflake entwickelte Snowpark, ursprünglich für die Migration von Spark-Workloads gedacht, mittlerweile aber eine Plattform für Python-basierte ML-Workloads. Zusätzlich investiert Snowflake stark in die Unterstützung von Apache Iceberg, damit Kunden ihre Data Lakes direkt aus Snowflake heraus verwalten und nutzen können.

Databricks wiederum brachte Features wie Photon und Databricks SQL auf den Markt und vergrößerte damit seine Präsenz im Data-Warehousing-Bereich.

Besonders deutlich wird das, wenn man die Oberflächen zum Anlegen eines Virtual Warehouse in Snowflake und eines "SQL Warehouse" in Databricks vergleicht. Databricks hat Design und Einstellungen der Snowflake Virtual Warehouses praktisch eins zu eins übernommen:

Nicht in der Timeline oben abgebildet: Beide Unternehmen haben Ende 2023 und Anfang 2024 zahlreiche AI/LLM-Features angekündigt. In diesem Bereich stehen wir noch am Anfang, aber beide haben große Übernahmen getätigt und investieren massiv.

Es lohnt sich, die Anfänge beider Unternehmen zu verstehen – sie erklären die jeweiligen Stärken und Schwächen der Plattformen.

Aufgrund seiner Wurzeln im Data Warehousing hat Snowflake ein deutlich stärkeres und ausgereifteres SQL-Data-Warehousing-Produkt. Für die meisten Unternehmen ist das die wichtigste und meistgenutzte Funktion – schließlich entsteht der Großteil des Mehrwerts einer Datenstrategie in einem gut verwalteten Data Warehouse, das zentrale Business-Intelligence-Use-Cases bedient.

Nur wenige Unternehmen, mit denen ich spreche, nutzen Databricks als ihr "Data Warehouse". Stattdessen setzen sie Databricks für seine leistungsstarken Python-Notebooks und die starke Unterstützung von Data-Science-Workloads ein. Für Unternehmen mit sehr technisch versierten Data Engineers, die lieber mit Apache Spark und Python arbeiten, ist Databricks oft die erste Wahl für Datentransformationen. Ein Vorteil von Databricks für ETL-Use-Cases ist die Flexibilität und Anpassbarkeit von Spark. Bei analytischen Workloads mit extrem großen Datensätzen kann Spark mitunter die bessere Wahl sein – man kann mehr Parameter feinjustieren und so den Job günstiger laufen lassen. Meiner Erfahrung nach lohnt sich diese Überlegung aber typischerweise erst bei Workloads, die mehrere Zehntausend Dollar pro Jahr kosten – denn die Personalkosten für Wartung und Programmierung dieser Pipelines übersteigen jede Einsparung auf der Compute-Seite oft schnell.

Mit Blick auf Roadmaps und Produktentwicklung ist Snowflakes Plattform-Fokus eines der zentralen Unterscheidungsmerkmale. Ende 2023 veröffentlichte Snowflake Snowpark Container Services, mit denen Kunden containerisierte Anwendungen in Snowflake ausführen können. Zusammen mit dem Native Application Marketplace wird klar: Snowflake baut für eine Zukunft, in der Kunden und Partner jede Art von Datenanwendung direkt in Snowflake betreiben können.

Databricks scheint dagegen den Weg zu gehen, Kunden für jeden Use Case eine Managed Solution out of the box zu bieten. Zwei klare Beispiele sind die Dashboard-Funktionalität und der Datenkatalog. Bei Snowflake setzen die meisten Kunden ein externes BI- bzw. Dashboard-Tool obendrauf. Genauso kaufen sie meist ein separates Datenkatalog-Produkt, um ihre Datasets zu verwalten. Databricks will diese Notwendigkeit, separate Tools zu kaufen, gezielt aushebeln. 2020 übernahm das Unternehmen Redash und entwickelte daraus ein starkes Out-of-the-Box-Dashboard-Angebot. Ähnlich investiert Databricks stark in Unity Catalog, das Drittanbieter-Datenkataloge ablösen soll.

Im Webinar sind wir die zentralen Use Cases einer Data-Cloud-Plattform durchgegangen und haben pro Use Case die Features von Databricks & Snowflake gegenübergestellt. Die wichtigsten Use Cases waren:

1. Data Ingestion
2. Data Transformations
3. Analyse & Reporting
4. ML/AI
5. Data Applications
6. Marketplace
7. Data Governance & Management

Schauen wir uns jeden Punkt im Detail an.

Data Ingestion

Bevor man mit Daten arbeiten kann, müssen sie zunächst geladen oder dem zugrunde liegenden System "bekannt gemacht" werden. Bei Snowflake läuft das meist über einen COPY INTO-Befehl, der die Daten in eine Tabelle lädt, die man dann mit Snowflake abfragen kann. Snowflake bietet außerdem Features wie Snowpipe, um Daten automatisiert zu laden.

Die meisten Snowflake-Kunden nutzen zusätzlich eine Drittanbieter-Lösung wie Fivetran, Stitch oder Airbyte, um Daten aus verschiedenen Quellen (Anwendungsdatenbanken, externe APIs etc.) in Snowflake zu laden.

Bei Databricks interagieren die meisten Kunden direkt mit den Daten im Cloud Storage. Managed Volumes ist allerdings ein ähnliches Konzept wie Snowflake-Tabellen – hier verwaltet Databricks die Tabelle.

Durch Snowflakes Investitionen in Apache Iceberg werden mehr Kunden ihre Daten direkt im Cloud Storage belassen und dort damit arbeiten – ähnlich wie beim Databricks-Modell.

Snowflake	Databricks
Klassisches COPY INTO	Autoloader
Snowpipe	Native Integrationen (z. B. S3)
First-Party-Konnektoren	Volumes
Drittanbieter (Fivetran/Stitch/Airbyte)	DBFS
Keine Ingestion nötig bei Nutzung von Iceberg

Data Transformations

Sobald die Daten in der Cloud-Plattform verfügbar sind, will man sie meist transformieren oder anreichern. Beide Plattformen bieten dafür verschiedene Lösungen.

Da Snowflake ein SQL-basiertes Data Warehouse ist, erledigen die meisten Kunden ihre Datentransformationen in reinem SQL – mit einer Kombination aus Tasks, Stored Procedures oder Drittanbieter-Tools für Transformation und Orchestrierung wie dbt. Sämtliche SQL-Workloads laufen in den Virtual Warehouses von Snowflake.

Bei Databricks nutzen die meisten Kunden Jobs: Damit lässt sich ein Spark-Job an einen Cluster übergeben, der auf Compute-Instanzen in der eigenen Cloud läuft. Durch Databricks' jüngste Investitionen in das Serverless-SQL-Warehouse-Produkt sieht man inzwischen immer häufiger reine SQL-Datentransformationen mit Tools wie dbt.

Snowflake	Databricks
Snowsight Dashboards	Notebook-Plots
Streamlit	SQL-Visualisierungen
First-Party-Konnektoren	Volumes
Drittanbieter (Tableau, Looker, PowerBI etc.)	Dashboards
	Drittanbieter (Tableau, Looker, PowerBI etc.)

Analyse & Reporting

Sowohl Databricks als auch Snowflake bieten ihren Kunden zahlreiche Funktionen für Analyse und Reporting. Mit Snowflake lassen sich schlanke Dashboards direkt in Snowsight bauen – oder eigene Datenanwendungen mit Streamlit.

Databricks hat ein sehr ausgereiftes Dashboard-Produkt, das manche Unternehmen anstelle eines externen BI-Tools einsetzen.

Snowflake	Databricks
Snowsight Dashboards	Notebook-Plots
Streamlit	SQL-Visualisierungen
First-Party-Konnektoren	Volumes
Drittanbieter (Tableau, Looker, PowerBI etc.)	Dashboards
	Drittanbieter (Tableau, Looker, PowerBI etc.)

ML/AI

Wie schon erwähnt, investieren beide Unternehmen stark in ML- und AI-Funktionen. Da Databricks hier früher den Schwerpunkt gesetzt hat, sind einige ML-Features wie Managed MLflow und Model Serving deutlich ausgereifter.

Mit dem Launch von Snowpark Container Services werden viele Snowflake-Kunden meiner Einschätzung nach bald in der Lage sein, ML-Modelle direkt in Snowflake zu hosten.

Snowflake	Databricks
Snowpark	MLflow
Snowpark Container Services	Model Serving
Snowflake Cortex	Starke Python-Unterstützung

Data Applications

Ein spannender Blickwinkel beim Vergleich von Snowflake und Databricks ist das Thema "Data Applications". Der Begriff ist zugegebenermaßen breit und interpretationsoffen – ich definiere eine "Data Application" hier als Produkt oder Feature, das Live-Daten oder Insights extern an Kunden außerhalb des eigenen Unternehmens ausspielt. Es geht also nicht um Anwendungen, die intern im Unternehmen genutzt werden.

Dank seines leistungsstarken SQL-Data-Warehouse bauen viele Unternehmen (wie SELECT) ihre Anwendungen direkt auf Snowflake auf und bedienen Application Queries direkt aus Snowflake Virtual Warehouses. Weitere Beispiele finden sich im Powered-By-Programm von Snowflake. Mit neuen Features wie Container Services wird es möglich sein, komplette Webanwendungen direkt in Snowflake zu hosten.

Bei Databricks wäre der Haupt-Use-Case für "externe Data Applications" das Model Serving. Ein vergleichbares SQL-Query-Serving dürfte aber durch die Investitionen in die Data-Warehousing-Produkte ebenfalls bald möglich werden.

Snowflake	Databricks
Apps aus Snowflake ausliefern	Model Serving
Unistore (HTAP) – Hybrid Tables	Jobs ad hoc auslösen
Data Sharing	Serverless SQL
Container Services

Marketplace

Als Kunde möchte man häufig zusätzliche Anwendungen oder Datasets beziehen, um sie in der Data-Cloud-Plattform zu nutzen. Hier liegt Snowflake klar vorn – mit einem sehr ausgereiften Marketplace voller Datasets und Native Applications, die sich direkt im Snowflake-Account ausführen lassen.

Snowflake	Databricks
Sehr ausgereifter Marketplace	Sehr ausgereifter Marketplace
Native Apps	Technologiepartner
Cost Management Suite	Deutlich weniger ausgereift, geringere Priorität
Starker Fokus auf Partner

Data Governance & Management

Im Bereich Governance und Management bieten beide Plattformen Out-of-the-Box-Funktionen.

Snowflake stellt allen Kunden hunderte Metadaten-Datasets kostenlos in der Account Usage Database bereit. Die Cost-Management-Suite ist sehr ausgereift und umfasst leistungsstarke Features wie Budgets und Resource Monitors. Kürzlich wurde Snowflake Horizon angekündigt – ein neues Funktionsset zur Governance von Datenbeständen und Nutzern.

Databricks hat mit Unity Catalog ein sehr starkes Datenkatalog-Angebot, das Kunden hilft, alle Daten in ihrer Umgebung zu verwalten und zu durchblicken. Beim Cost Management hinkt Databricks deutlich hinterher und hat diese Daten erst kürzlich in System Tables verfügbar gemacht (das Databricks-Pendant zu Snowflakes Account Usage Views).

Snowflake	Databricks
Hunderte Metadaten-Datasets (Account Usage / Information Schema)	Unity Catalog
Snowflake Horizon	System Tables
Cost Management Suite	Compute-Metriken
	Compute-Metriken

Sowohl Databricks als auch Snowflake setzen auf nutzungsbasierte Preise – Sie zahlen für das, was Sie tatsächlich verbrauchen. Mehr zum Preismodell von Snowflake erfahren Sie in unserem Beitrag hier. Informationen zum Databricks-Pricing finden Sie auf deren Website. Wichtig beim Databricks-Pricing: Es gibt zwei Arten von Kosten:

1. Die Overhead- bzw. Plattformkosten von Databricks
2. Die zugrunde liegenden Cloud-Kosten von AWS/Azure/GCP für die Server, die Databricks in diesen Accounts hochfährt

Wie bei jeder nutzungsbasierten Cloud-Plattform können die Kosten schnell durch die Decke gehen, wenn sie nicht angemessen verwaltet und überwacht werden.

Ist Databricks günstiger als Snowflake?

Eine häufig gestellte Frage ist, ob Databricks günstiger ist als Snowflake. Befeuert wird das Ganze teilweise durch massive Marketing-Anstrengungen von Databricks – siehe das Bild von deren Website:

Bei der Kostenbetrachtung eines Datenprozesses oder einer Anwendung sind zwei Faktoren entscheidend:

1. Die Plattformkosten. Das Geld, das Sie an Databricks, Snowflake oder Ihren Cloud-Anbieter zahlen.
2. Die Personalkosten. Das Geld, das Sie Ihren Mitarbeitenden zahlen, die die Anwendungen und Prozesse bauen und betreiben.

Databricks behauptet, dass sich ETL-Workloads deutlich günstiger als in Snowflake ausführen lassen. Diese Behauptung beruht darauf, dass sich Spark-Jobs sehr fein tunen lassen. Es gibt unzählige Parameter, mit denen Engineers Tage – oder Wochen – experimentieren und feinjustieren können.

Was bei solchen Vergleichen oft unter den Tisch fällt – auch im Databricks-Marketing – sind die Personalkosten für diese Arbeit. In manchen Fällen kann es sinnvoll sein, Engineers für das Optimieren und Tunen eines Jobs zu bezahlen. Bei den meisten ETL-Workloads sorgt der Personalaufwand jedoch dafür, dass die Gesamtkosten am Ende höher liegen.

Bei allen Kostenvergleichen zwischen den Plattformen sollten Sie also stets die Total Cost of Ownership im Blick haben – sowohl (a) den Plattformanbieter als auch (b) die Menschen, die die Arbeit leisten.

Da Databricks ein privates Unternehmen ist, werden weder die genaue Kundenzahl noch die Marktdurchdringung in einzelnen Segmenten öffentlich gemacht.

Im Webinar haben wir auch darüber gesprochen, wie viele Kunden beide Plattformen parallel nutzen. Die Zahlen in der Folie unten sind nicht verifiziert, zeigen aber eine wachsende Überschneidung zwischen beiden Plattformen.

Jeff und ich vermuten, dass diese Überschneidung auf den historisch unterschiedlichen Fokus der beiden Plattformen zurückgeht, der inzwischen konvergiert.

Ian Whitestone · Co-Founder & CEO von SELECT

Ian ist Co-Founder & CEO von SELECT, einer SaaS-Plattform für Snowflake-Cost-Management und -Optimierung. Vor SELECT leitete Ian sechs Jahre lang Full-Stack-Data-Science- und Engineering-Teams bei Shopify und Capital One. Bei Shopify verantwortete er die Optimierung des Data Warehouse und den Ausbau der Kostentransparenz.