Snowflake seit 2012 und Databricks seit 2013: Wie das Lakehouse den Modern Data Stack umbaut

Der Begriff „Modern Data Stack” ist um 2020 herum von amerikanischen Venture-Capital-Geldgebern in die Welt gesetzt worden — als Sammelbegriff für eine Generation von Datenwerkzeugen, die das klassische Data-Warehouse-Paradigma von Bill Inmons „Building the Data Warehouse” (1992) und Ralph Kimballs „Data Warehouse Toolkit” (1996) ablösen sollten. Sechs Jahre später lässt sich nüchtern festhalten: Das klassische DWH ist nicht abgelöst, sondern transformiert worden — und die beiden Plattformen, an denen sich diese Transformation am sichtbarsten vollzieht, heißen Snowflake und Databricks.

Zwei Gründungs­geschichten, zwei Architekturphilosophien

Snowflake sei im Juli 2012 in San Mateo gegründet worden — von Benoit Dageville, Thierry Cruanes und Marcin Żukowski, drei Datenbank-Spezialisten mit Wurzeln in Oracle, Microsoft und der Vectorwise-Forschung. Die zentrale technische Innovation war die Trennung von Compute und Storage in einer Weise, die in der Welt der klassischen MPP-Datenbanken — Teradata, Netezza, Vertica — nicht vorgesehen war. Snowflake speicherte die Daten in S3 (später auch in Azure Blob Storage und Google Cloud Storage), während die Rechenleistung über sogenannte Virtual Warehouses dynamisch hinzu- und weggeschaltet werden konnte.

Am 16. September 2020 erfolgte der NYSE-Börsengang — mit einer initialen Bewertung von rund 33,2 Milliarden US-Dollar einer der größten Software-Börsengänge der Dekade. Der Aktienkurs hat seither erhebliche Volatilität erlebt; an der grundlegenden Marktposition als das wahrgenommene Cloud-Data-Warehouse hat das wenig geändert.

Databricks habe demgegenüber eine andere Genese. Das Unternehmen sei 2013 in San Francisco gegründet worden, von einem Team um Ali Ghodsi und Matei Zaharia, das aus dem AMPLab der University of California, Berkeley stammte. Aus der Apache-Spark-Entwicklung — Spark wurde zur Top-Level-Apache-Project im Februar 2014 — entstand zunächst ein Plattformdienst, der das Betreiben von Spark-Clustern in der Cloud vereinfachen sollte. In den Folgejahren erweiterte sich der Anspruch: vom Daten-Engineering-Werkzeug zur „Data Intelligence Platform” mit MLflow, Unity Catalog und seit 2019 Delta Lake als transaktionalem Storage-Layer.

In der Series-J-Finanzierungsrunde im Dezember 2024 sei Databricks mit rund 62 Milliarden US-Dollar bewertet worden — eine Größenordnung, die das Unternehmen ohne Börsengang in die Reihe der wertvollsten Privatfirmen der Welt katapultiert.

Der Vorläufer: BigQuery und Redshift

Eine ehrliche Sortierung muss anerkennen, dass weder Snowflake noch Databricks der erste Cloud-Data-Warehouse-Anbieter war. Google hat BigQuery im Mai 2010 öffentlich angekündigt — basierend auf dem internen Dremel-System, das seit 2006 in Google produktiv im Einsatz ist. Amazon Redshift wurde im Februar 2013 allgemein verfügbar — Monate vor der Gründung von Databricks und gut anderthalb Jahre nach der Gründung von Snowflake.

Was Snowflake und Databricks von BigQuery und Redshift unterscheidet, ist die plattform­unabhängige Positionierung. Beide Firmen sind auf AWS, Azure und Google Cloud verfügbar — eine bewusste Entscheidung, die ihnen den Zugang zu Kunden mit Multi-Cloud-Strategie öffnete und die sie gegen die Hyperscaler-Ökosysteme verteidigte.

Der Lakehouse-Begriff und die zwei Konvergenz­bewegungen

„Lakehouse” — der Begriff stammt aus einem CIDR-Konferenzpapier von 2021, an dem Forscher von Databricks mitarbeiteten — bezeichnet eine Architektur, in der die Vorteile des Data Warehouse (Transaktionalität, Konsistenz, Performance auf strukturierten Daten) mit den Vorteilen des Data Lake (offene Formate, Skalierbarkeit, niedrige Storage-Kosten) verbunden werden sollen. Der entscheidende technische Hebel sind transaktionale Tabellenformate auf Object Storage: Delta Lake (Databricks, seit 2019), Apache Iceberg (Netflix, Open-Source seit 2018) und Apache Hudi (Uber, seit 2017).

Bis etwa 2023 war die Lakehouse-Erzählung weitgehend ein Databricks-Versprechen — Snowflake widersprach und argumentierte für sein proprietäres FDN-Tabellenformat. Die strategische Wende vollzog sich auf der Snowflake Summit 2024, als das Unternehmen Iceberg-Tabellen als Erstbürger der Plattform ankündigte. Wenige Wochen später, im Juni 2024, sei die Akquisition von Tabular — der Firma der Iceberg-Schöpfer Ryan Blue und Daniel Weeks — durch Databricks bekannt geworden. Beide Plattformen positionieren sich seither um die offenen Tabellenformate, ohne dass die strategischen Spannungen damit verschwunden wären.

Aus DACH-Sicht ist diese Konvergenz von größerer Bedeutung, als es auf den ersten Blick scheint. Deutsche Großkonzerne — Automobilbauer, Energie­versorger, Versicherer — haben in den vergangenen fünf Jahren erhebliche Investitionen in Datenplattformen vorgenommen, oft in der Hoffnung, die Bindung an einen einzelnen Hersteller niedrig zu halten. Iceberg als gemeinsames Format, verwaltet über einen unabhängigen Katalog (Polaris, Unity Catalog Open-Source oder die Tabular-Implementierung), ist das technische Versprechen, das diese Hoffnung trägt.

dbt und die Transformation-Schicht

Eine vollständige Sortierung des Modern Data Stack lässt sich nicht ohne dbt erzählen — das von Tristan Handy und Drew Banin 2016 in Philadelphia begründete Werkzeug zur SQL-basierten Datenmodellierung. dbt habe in der DACH-Daten-Engineering-Community in den vergangenen drei Jahren einen Status erreicht, den vor fünf Jahren noch niemand vorhergesagt hätte. Die SQL-zentrierte Modellierung mit ihrem Jinja-Templating, ihrer Versionskontrolle über Git und ihrer integrierten Test-Logik hat eine Praxis etabliert, die sich von der klassischen Informatica- oder Talend-ETL-Welt erkennbar unterscheidet.

Wo dbt steht, steht eine bestimmte Kultur der Datenmodellierung: das Kimball-Sternschema, fortgeschrieben in der dimensional-modellierten Marts-Schicht; Data Vault — methodisch begründet von Dan Linstedt um das Jahr 2000 — als Variante für historisierungs­sensible Domänen; und eine wachsende Zahl von DACH-Beratungshäusern, die sich auf eine dbt-Plus-Lakehouse-Praxis spezialisieren.

Modern Data Stack oder Data Mesh?

Eine zweite Strömung — die nicht direkt mit Snowflake und Databricks zusammenhängt, aber im DACH-Architektur­gespräch dauerhaft präsent ist — sei das Data-Mesh-Konzept, das Zhamak Dehghani 2019 in einem Martin-Fowler-Blogartikel skizzierte. Data Mesh argumentiert für eine domänen­zentrierte Datenarchitektur, in der die fachlichen Bereiche eines Unternehmens — Vertrieb, Logistik, Personal — ihre eigenen „Data Products” verantworten und über föderierte Standards austauschen.

In der DACH-Praxis ist Data Mesh eher ein Organisations- als ein Technologie­konzept. Implementiert auf Snowflake oder Databricks bedeutet es: mehrere Workspaces oder Accounts, einen gemeinsamen Katalog (Unity oder Polaris), eine Governance-Schicht, die Datenverträge zwischen Domänen ermöglicht. Das funktioniert in einem reifen Großkonzern; in einem Mittelständler mit 200 Datenanalysten ist es — vorsichtig formuliert — Overkill.

Die ökonomische Wette: Wer bezahlt am Ende?

Die strategisch interessanteste Frage an die Lakehouse-Generation ist die ökonomische. Snowflake rechnet seine Lizenz­modelle nach verbrauchten Compute-Credits ab; Databricks ebenso. Beide Modelle haben in den vergangenen drei Jahren bei DACH-Großkunden zu Budget­überraschungen geführt — Implementierungen, deren Kostenstruktur sich erst dann manifestierte, als die Nutzungszahlen das ursprünglich Geplante deutlich überstiegen.

Die Antwort des Marktes ist eine wachsende Sub-Industrie spezialisierter Cost-Optimization-Berater: Werkzeuge wie Capital One Slingshot, das Open-Source-Werkzeug Select.dev oder die zahlreichen FinOps-Aufsätze, die sich auf die Beobachtung und Steuerung von Warehouse- und Compute-Kosten konzentrieren. Wer eine Snowflake- oder Databricks-Strategie ohne FinOps-Komponente plant, sei — vorsichtig formuliert — gewarnt.

Was die DACH-Datenarchitektur konkret entscheiden muss

Aus der Vogelperspektive lassen sich vier Entscheidungsachsen ableiten, an denen sich DACH-Datenarchitekten in den kommenden Monaten orientieren werden. Erstens die Frage des Tabellen­formats: Iceberg, Delta, Hudi — oder eine bewusste Multi-Format-Strategie? Die Wahl ist nicht trivial, denn sie wirkt sich auf die Kompatibilität mit Tools wie Spark, Trino, DuckDB und den Streaming-Frameworks der Apache-Kafka-Welt aus.

Zweitens die Frage des Katalog-Layers. Wer Iceberg-Tabellen plattform­übergreifend nutzen will, braucht einen Katalog, der diese Tabellen verwaltet — Polaris (Snowflake), Unity Catalog Open-Source (Databricks), die Tabular-Implementierung oder die zahlreichen Eigen­entwicklungen, die in der Apache-Welt existieren. Die strategische Frage ist, wie viel Lock-in eine Organisation in diesem Layer akzeptiert.

Drittens die Frage der Transformations­schicht. dbt ist heute der dominante Standard für SQL-basierte Modellierung, aber die Konkurrenz wächst — von SQLMesh über Coalesce bis zu den nativen Modellierungs­werkzeugen der großen Plattformen. Eine zukunfts­offene Architektur sollte hier keine zu enge Bindung an einen einzelnen Anbieter eingehen.

Viertens die Frage der KI-Inferenz-Schicht. Wenn die Lakehouse-Generation tatsächlich der Daten­untergrund für Generative-KI-Anwendungen wird, dann müssen Vector-Stores, Embedding-Pipelines und Modell-Hosting-Infrastrukturen Teil der Datenplattform­strategie werden. Beide Anbieter haben in den vergangenen achtzehn Monaten massiv in diesen Bereich investiert — Databricks mit der Mosaic-AI-Akquisition aus 2023, Snowflake mit der Cortex-Familie. Welche Strategie sich durchsetzt, ist im Frühjahr 2026 noch nicht entschieden.

Das DACH-spezifische Souveränitäts­thema

Eine Dimension, die in der amerikanisch dominierten Modern-Data-Stack-Erzählung systematisch unterbelichtet bleibt, ist die DACH-spezifische Sensibilität für digitale Souveränität. Die Schrems-II-Entscheidung des EuGH vom 16. Juli 2020, die den EU-US-Privacy-Shield für unwirksam erklärte, hat in deutschen Konzernen — vor allem in regulierten Branchen wie Finanzdienstleistungen, Versicherungen und Gesundheits­wesen — eine bleibende Vorsicht gegenüber amerikanischen Cloud-Anbietern hinterlassen. Snowflake und Databricks adressieren diese Sorge mit europäischen Rechenzentren — Frankfurt für AWS, Dublin und Amsterdam für die anderen Hyperscaler — und mit Customer-Managed-Keys-Funktionalität, die die Kontrolle über die Verschlüsselungs­schlüssel beim Kunden belässt.

Das EU-US-Data-Privacy-Framework, das im Juli 2023 als Nachfolger des Privacy-Shields in Kraft trat, hat die rechtliche Lage temporär stabilisiert; eine erneute juristische Überprüfung — Schrems III — sei jedoch nicht ausgeschlossen. Wer eine Snowflake- oder Databricks-Strategie auf zehn Jahre plant, sollte die Möglichkeit eines erneuten Datenschutz-Rückschlags einkalkulieren.

Parallel dazu entsteht im DACH-Raum eine alternative Strömung — die der europäischen Souveränen Cloud-Anbieter. T-Systems, OVHcloud, IONOS, der Stackit-Stack von Schwarz IT — all das sind Versuche, eine plattform-unabhängige Cloud-Infrastruktur zu bieten, die nicht dem US-CLOUD-Act unterliegt. Snowflake und Databricks haben hier (noch) keine direkte Antwort; ihre Plattformen laufen ausschließlich auf den drei großen US-Hyperscalern. Welche Folgen das langfristig für die DACH-Marktposition hat, ist Gegenstand offener Beobachtung.

Fazit

Snowflake und Databricks repräsentieren zwei sehr unterschiedliche Genese-Linien — die klassische Datenbank-Tradition versus die Spark-und-Notebook-Welt — und sie konvergieren seit 2024 erkennbar in der Lakehouse-Architektur. Das ist gleichzeitig ihre Stärke und ihre strategische Verwundbarkeit: Wenn das Iceberg-Versprechen einer wirklich offenen Tabellenschicht eingelöst wird, verlieren beide Anbieter einen Teil ihrer Lock-in-Position. Wenn es nicht eingelöst wird, bleibt das Versprechen ein Marketing-Beruhigungsmittel für IT-Leiter, die sich vor Vendor-Lock-in fürchten.

Das DACH-Daten-Engineering wird in den kommenden Jahren entscheiden müssen, ob die Lakehouse-Architektur die strukturelle Lösung für die zentrale Frage der nächsten Dekade ist: Wie organisieren wir Datenplattformen so, dass Generative-KI-Anwendungen — von RAG-Systemen über Co-Piloten bis hin zur tatsächlichen Modell-Inferenz — auf konsistenten, governiert verwalteten Daten operieren können? Davon mehr in einer kommenden Ausgabe.