Der entscheidende Unterschied zu einer herkömmlichen Datenbank: Snowflake müssen Sie nicht betreiben. Es gibt keine Server, keine Indizes, keine Partitionierung, kein Patch-Management und kein Tuning im klassischen Sinn. Sie laden Ihre Daten, schreiben SQL – und Snowflake kümmert sich um den Rest. Diese Form von „Software as a Service“ für ein Data Warehouse war 2014 neu und hat den Markt nachhaltig verändert. Für den deutschen Mittelstand, der selten ein eigenes Datenbank-Betriebsteam unterhält, ist genau das oft das ausschlaggebende Argument.
Drei Eigenschaften definieren Snowflake:
In Gesprächen werden die Begriffe oft durcheinandergeworfen. Eine Datenbank im klassischen Sinn (etwa PostgreSQL oder Microsoft SQL Server) ist für das schnelle Schreiben und Lesen einzelner Datensätze in operativen Anwendungen optimiert. Ein Data Warehouse ist dagegen für analytische Abfragen über große Datenmengen ausgelegt – also für Fragen wie „Wie hat sich der Deckungsbeitrag pro Region über die letzten drei Jahre entwickelt?“. Snowflake ist im Kern ein solches analytisches Data Warehouse, geht aber darüber hinaus.
Der Begriff Data Cloud beschreibt die Erweiterung um Funktionen, die ein reines Warehouse nicht hätte: das geregelte Teilen von Daten zwischen Organisationen, einen Marktplatz für externe Datensätze, die Verarbeitung halbstrukturierter Daten und zunehmend integrierte KI-Werkzeuge. Für die Praxis ist die Unterscheidung weniger wichtig als das Verständnis: Snowflake ist der zentrale Ort, an dem Ihre Analysedaten leben – und von dem aus Berichte, Dashboards und Datenprodukte gespeist werden.
Ein Virtual Warehouse ist ein benannter, unabhängiger Rechen-Cluster. Sie definieren eine T-Shirt-Größe – von XS über S, M, L bis hin zu mehrfach extragroßen Clustern – und Snowflake stellt die entsprechende Rechenkapazität bereit. Jede Größenstufe verdoppelt grob die Leistung und damit den Verbrauch an Credits. Der Clou: Ein Warehouse kann in Sekunden starten und sich nach einer konfigurierbaren Leerlaufzeit automatisch wieder anhalten („Auto-Suspend“). Solange es angehalten ist, kostet es nichts.
In der Praxis bedeutet das eine völlig neue Form der Ressourcen-Planung. Statt einen großen Server für die Spitzenlast vorzuhalten und ihn die meiste Zeit zu unterfordern, weisen Sie jeder Arbeitslast genau die passende Größe zu: ein kleines Warehouse für tägliche Dashboards, ein großes für den nächtlichen Ladelauf, ein mittleres für die Data-Science-Abteilung. Diese Aufteilung ist auch der wichtigste Hebel zur Kostenkontrolle – ein zu groß dimensioniertes oder dauerhaft laufendes Warehouse ist die häufigste Ursache überraschend hoher Rechnungen.
Reicht ein einzelnes Warehouse bei vielen gleichzeitigen Nutzern nicht aus, kommt das Multi-Cluster-Warehouse ins Spiel. Steigt die Zahl paralleler Abfragen über eine Schwelle, startet Snowflake automatisch zusätzliche Cluster derselben Größe und verteilt die Last; sinkt die Nachfrage, werden die zusätzlichen Cluster wieder beendet. Für ein Unternehmen mit Lastspitzen – etwa zum Monatsabschluss, wenn alle Abteilungen gleichzeitig ihre Berichte ziehen – ist das ein großer Vorteil: Es gibt keine Warteschlangen, ohne dass dauerhaft teure Kapazität bereitsteht.
Wichtig zu verstehen ist der Unterschied zweier Skalierungsrichtungen. Eine größere Warehouse-Stufe (Scale-up) macht einzelne, komplexe Abfragen schneller. Mehr Cluster (Scale-out, Multi-Cluster) bedienen mehr gleichzeitige Nutzer. Beide Hebel werden oft verwechselt – und die falsche Wahl ist sowohl ein Performance- als auch ein Kostenproblem. Aus unserer Beratungspraxis ist das einer der Punkte, an denen sich gute Snowflake-Implementierungen von schlechten unterscheiden.
Zwei dieser Funktionen wirken auf den ersten Blick wie technische Spielerei, entfalten in der Praxis aber enormen Nutzen. Time Travel bedeutet, dass ein fehlerhafter Ladelauf, ein versehentliches Überschreiben oder ein falsch ausgeführtes Update kein Drama mehr ist: Sie fragen schlicht den Zustand „vor der Änderung“ ab und stellen ihn wieder her. Was früher ein nächtlicher Restore aus dem Backup war, ist nun ein einzelnes SQL-Statement. Der Zeitraum ist konfigurierbar und wirkt sich auf die Speicherkosten aus – ein typischer Wert sind ein bis wenige Tage, für besonders kritische Daten auch länger.
Zero-Copy-Cloning wiederum löst ein altes Problem der Datenarbeit: Wie testet man Änderungen an echten, großen Datenbeständen, ohne sie teuer zu duplizieren? Snowflake erstellt einen Klon, der zunächst nur auf dieselben gespeicherten Daten verweist; physischer Speicher entsteht erst durch Abweichungen. So lässt sich in Sekunden eine vollständige Testkopie der Produktivdaten anlegen, an der ein Entwicklerteam gefahrlos arbeitet – ein Muster, das saubere Test- und Freigabe-Prozesse erst praktikabel macht.
Ein oft unterschätzter Vorteil ist der Umgang mit semi-strukturierten Daten. Viele moderne Datenquellen – Webshop-Events, IoT-Sensoren, API-Antworten – liefern JSON statt sauberer Tabellen. In klassischen Warehouses müssen diese Daten erst mühsam in Spalten zerlegt werden, bevor man sie analysieren kann. Snowflake speichert sie über den Datentyp VARIANT nativ und erlaubt, einzelne Felder mit normaler SQL-Syntax direkt anzusprechen. Das verkürzt Integrationsprojekte spürbar und macht die Plattform flexibel gegenüber sich ändernden Datenstrukturen – ein Punkt, der gerade bei wachsenden Digitalprodukten im Mittelstand zählt.
Ein klassisches Data Warehouse arbeitet mit strukturierten, aufbereiteten Daten und ist auf zuverlässige, schnelle SQL-Analysen optimiert. Ein Data Lake sammelt dagegen rohe Daten aller Art – strukturiert wie unstrukturiert – kostengünstig im Objektspeicher, ist aber ohne zusätzliche Werkzeuge schwer zu beherrschen. Das Lakehouse verspricht, beide Welten zu vereinen: die Flexibilität und niedrigen Speicherkosten eines Lakes mit der Struktur und Abfrage-Stärke eines Warehouses. Databricks hat diesen Begriff geprägt.
Snowflake ist historisch aus der Data-Warehouse-Welt gekommen und dort am stärksten: SQL-Analysen, Business Intelligence, saubere, governance-fähige Datenmodelle. In den letzten Jahren hat es sich jedoch deutlich in Richtung Lakehouse erweitert – mit der Unterstützung offener Tabellenformate, externer Tabellen auf Cloud-Speicher und der Verarbeitung halbstrukturierter Daten. Databricks wiederum kommt aus der Data-Science- und Data-Engineering-Welt (mit Wurzeln in Apache Spark) und hat sich umgekehrt in Richtung klassischer BI-Abfragen entwickelt. Die beiden Plattformen wachsen also aufeinander zu – die Grenzen verschwimmen.
Aus unserer Beratungspraxis kristallisieren sich klare Muster heraus. Snowflake ist meist die richtige Wahl, wenn der Schwerpunkt auf klassischer Analytik und Business Intelligence liegt, wenn das Team primär in SQL denkt und wenn Sie eine cloud-neutrale Plattform wollen, die sich nicht an einen einzelnen Hyperscaler bindet. Die einfache Bedienung – im Kern „nur SQL“ – senkt die Einstiegshürde im Mittelstand erheblich.
Databricks spielt seine Stärken aus, wenn anspruchsvolles Data Engineering, große Streaming-Pipelines und insbesondere fortgeschrittenes Machine Learning im Zentrum stehen und das Team über entsprechendes Code-Know-how verfügt. BigQuery ist oft die naheliegendste Lösung, wenn ein Unternehmen ohnehin tief in der Google-Cloud-Welt verankert ist. Wichtig: Es gibt selten ein objektiv „bestes“ System – die richtige Wahl hängt von Datenstrategie, vorhandenen Kompetenzen und bestehender Cloud-Landschaft ab. Genau das ist Gegenstand einer seriösen Vorab-Bewertung.
Der typische Aufbau in unseren Projekten sieht so aus: Snowflake ist die „Single Source of Truth“ – der eine, verlässliche Ort, an dem alle Analysedaten zusammenlaufen, sauber modelliert und mit Zugriffsrechten versehen. Darüber sitzen die BI-Werkzeuge, mit denen die Fachabteilungen arbeiten. Weil die Rechenleistung in Snowflake liegt, bleiben die BI-Tools schlank: Sie schicken Abfragen an Snowflake und stellen nur die Ergebnisse dar. Das hält auch große Datenmengen handhabbar.
Für den deutschen Mittelstand ist Microsoft Power BI das mit Abstand verbreitetste BI-Werkzeug – und die Kombination mit Snowflake ist ausgereift. Power BI verbindet sich über einen nativen Connector mit Snowflake und bietet zwei grundsätzliche Modi: Im Import-Modus werden Daten in das Power-BI-Datenmodell geladen und dort gehalten – sehr schnell für die Nutzer, aber mit dem Nachteil regelmäßiger Aktualisierungen und Größenbeschränkungen. Im DirectQuery-Modus bleibt die Rechenlast in Snowflake; Power BI reicht jede Interaktion als Abfrage durch. Das hält die Daten stets aktuell und ist für sehr große Modelle die richtige Wahl – verlagert aber Last (und damit Credits) zu Snowflake.
Die Wahl zwischen Import und DirectQuery ist eine der wichtigsten Architektur-Entscheidungen und hat unmittelbare Auswirkungen auf Performance, Aktualität und Kosten. In der Praxis bewährt sich häufig ein gemischter Ansatz: häufig genutzte, kleinere Aggregate im Import, große Detaildaten per DirectQuery. Wer hier unbedacht alles auf DirectQuery stellt und schlecht modellierte Berichte baut, erzeugt schnell eine Vielzahl kleiner Abfragen – und damit unnötigen Credit-Verbrauch.
Tableau, ebenfalls weit verbreitet, gilt vielen als das stärkste Werkzeug für explorative, visuell anspruchsvolle Analysen und harmoniert sehr gut mit Snowflake. Auch hier gibt es die Wahl zwischen einem Extrakt (Daten in Tableau) und einer Live-Verbindung (Rechenlast in Snowflake). Daneben verbinden sich praktisch alle relevanten Plattformen mit Snowflake – von Qlik über Looker bis hin zu schlankeren, modernen Werkzeugen. Diese Werkzeug-Neutralität ist strategisch wertvoll: Sie können das BI-Frontend wechseln, ohne die darunterliegende Datenplattform anzutasten.
Ein häufig übersehener Baustein ist die Transformations-Schicht zwischen Rohdaten und BI. Werkzeuge wie dbt modellieren die Daten direkt in Snowflake zu sauberen, dokumentierten und getesteten Analysetabellen, bevor sie ins BI-Tool gelangen. Dieser Schritt entscheidet maßgeblich über die Qualität und Vertrauenswürdigkeit der späteren Berichte – und ist aus unserer Sicht kein Nice-to-have, sondern Pflicht für eine belastbare Analytics-Landschaft.
Die Grundidee folgt einem klaren Prinzip: Bring den Code zu den Daten, nicht die Daten zum Code. Statt große Datenmengen aus Snowflake herauszukopieren, sie in einer separaten Umgebung zu verarbeiten und die Ergebnisse zurückzuspielen, lässt Snowflake die Berechnung direkt dort laufen, wo die Daten liegen. Das reduziert Datenbewegungen, vereinfacht die Governance und hält sensible Daten innerhalb der kontrollierten Plattform – ein Aspekt, der gerade unter Datenschutz-Gesichtspunkten relevant ist.
Snowpark ist eine Entwickler-Schnittstelle, die es erlaubt, in vertrauten Programmiersprachen – vor allem Python, daneben Java und Scala – direkt gegen Snowflake-Daten zu programmieren. Data-Science-Teams können Daten aufbereiten, Modelle trainieren und Funktionen ausführen, ohne die Plattform zu verlassen. Für Unternehmen heißt das: Die Data-Science-Abteilung arbeitet auf denselben, governance-konformen Daten wie die BI-Abteilung, in einer Umgebung, statt parallele Daten-Inseln aufzubauen. Das ist organisatorisch oft genauso wertvoll wie technisch.
Realistisch eingeordnet: Snowpark ist für Datenaufbereitung, Feature-Erstellung und das Betreiben von Modellen sehr leistungsfähig. Für hochspezialisierte Deep-Learning-Forschung mit großen GPU-Anforderungen ist eine spezialisierte ML-Plattform wie Databricks weiterhin oft die naheliegendere Wahl. Im typischen Mittelstands-Szenario – Prognosen, Klassifikationen, Segmentierungen auf strukturierten Unternehmensdaten – deckt Snowpark den Bedarf jedoch gut ab.
Snowflake Cortex bündelt KI-Funktionen, die sich per SQL aufrufen lassen, ohne dass eigene Modelle betrieben werden müssen. Dazu gehören klassische ML-Funktionen für Prognosen und Anomalie-Erkennung ebenso wie der Zugriff auf große Sprachmodelle (LLMs) für Aufgaben wie Zusammenfassung, Übersetzung, Sentiment-Analyse oder die Beantwortung von Fragen an die eigenen Daten. Der Reiz liegt darin, dass diese Funktionen innerhalb der Plattform laufen – die Daten bleiben in Snowflake, statt an einen externen KI-Dienst gesendet zu werden.
Damit lässt sich beispielsweise eine natürlichsprachliche Analyse von Freitext-Feldern – Kundenfeedback, Servicetickets, Berichte – direkt im Data Warehouse umsetzen, oder eine Frage-Antwort-Funktion über interne Dokumente aufbauen. Aus Beratungssicht ist das eine vielversprechende, aber noch junge und sich schnell entwickelnde Funktionsfamilie. Wir empfehlen, Cortex zunächst in klar abgegrenzten Anwendungsfällen zu erproben, statt darauf eine geschäftskritische Architektur aufzubauen – und dabei die anfallenden Kosten genau im Blick zu behalten, da KI-Funktionen verbrauchsabhängig abgerechnet werden.
Snowflake rechnet im Kern über zwei Komponenten ab: Speicher und Rechenleistung. Der Speicher wird pro gespeichertem Datenvolumen und Monat berechnet und ist in der Regel der kleinere, gut planbare Teil der Rechnung. Die Rechenleistung wird in sogenannten Credits abgerechnet: Ein laufendes Virtual Warehouse verbraucht pro Zeiteinheit eine bestimmte Zahl an Credits – abhängig von seiner Größe. Größere Warehouses und länger laufende Warehouses verbrauchen mehr. Der Credit-Preis selbst hängt von Edition, Cloud-Anbieter und Region ab und ist Verhandlungssache; konkrete Eurobeträge variieren entsprechend und ändern sich laufend.
Die häufigste böse Überraschung entsteht nicht durch Snowflake selbst, sondern durch unbedachte Nutzung. Typische Ursachen aus unserer Beratungspraxis:
Die gute Nachricht: Snowflake gibt Ihnen wirksame Werkzeuge an die Hand, um Kosten zu steuern. Wer sie konsequent nutzt, behält die Ausgaben im Griff.
Aus unserer Sicht ist die Kostensteuerung kein einmaliges Setup, sondern eine laufende Disziplin – vergleichbar mit dem bewussten Umgang mit Cloud-Ausgaben generell (oft als „FinOps“ bezeichnet). Unternehmen, die von Anfang an klare Verantwortlichkeiten, Budgets und Monitoring etablieren, erleben Snowflake als planbar und wirtschaftlich. Unternehmen, die das vernachlässigen, erleben es als Kostenfalle. Der Unterschied liegt nicht in der Technik, sondern in der Governance.
Der wichtigste Hebel für die Datenhoheit ist die Wahl der Region. Snowflake läuft auf AWS, Azure und Google Cloud und ist in zahlreichen Regionen weltweit verfügbar – darunter mehrere in der Europäischen Union, etwa in Frankfurt. Wer eine EU-Region wählt, sorgt dafür, dass die gespeicherten Daten physisch in europäischen Rechenzentren liegen. Das ist eine notwendige Grundlage für einen DSGVO-konformen Betrieb und reduziert das Risiko, dass Daten unbeabsichtigt in Drittländer abfließen.
Snowflake stellt für den Einsatz in Europa die üblichen vertraglichen Instrumente bereit – insbesondere einen Auftragsverarbeitungsvertrag (AVV) und Standardvertragsklauseln. Zudem verfügt der Anbieter über etablierte Zertifizierungen und Sicherheitsstandards, die in Ausschreibungen und Compliance-Prüfungen regelmäßig gefordert werden. Diese Bausteine sind wichtig, ersetzen aber nicht die eigene Prüfung des konkreten Anwendungsfalls.
Auch bei Speicherung in einer EU-Region bleibt ein grundsätzliches Thema bestehen: Snowflake ist ein US-Mutterkonzern, und die genutzte Infrastruktur stammt von US-Hyperscalern. Damit unterliegt das Unternehmen potenziell US-amerikanischem Recht – ein Punkt, der seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird. Die EU-Region adressiert den Aspekt der Datenlokalisierung, beseitigt aber nicht jedes theoretische Zugriffsrisiko, das aus der US-Konzernzugehörigkeit folgen könnte.
In der Praxis ist dieses Restrisiko für viele Mittelständler mit überschaubar sensiblen Analysedaten vertretbar – insbesondere mit EU-Region, sauberem AVV, Verschlüsselung und einer durchdachten Datenminimierung. Für besonders schützenswerte Datenkategorien, für Berufsgeheimnisträger oder für Unternehmen mit hohen Souveränitätsanforderungen kann die Bewertung anders ausfallen. Dann sind zusätzliche Schutzmaßnahmen, eine Datenschutz-Folgenabschätzung oder – je nach Schutzbedarf – europäische bzw. souveräne Alternativen zu prüfen. Diese Abwägung ist der Kern jeder seriösen Vorab-Bewertung.
Der häufigste Fehler ist, Snowflake als Selbstzweck einzuführen – „weil alle eine Data Cloud haben“. Erfolgreiche Projekte starten umgekehrt: mit einem konkreten, schmerzhaften Geschäftsproblem. Typische Einstiegs-Use-Cases im Mittelstand sind etwa ein abteilungsübergreifendes Vertriebs- und Deckungsbeitrags-Reporting, das heute mühsam aus mehreren Systemen in Excel zusammengetragen wird; eine Zusammenführung von ERP-, CRM- und Webshop-Daten zu einer 360-Grad-Sicht auf den Kunden; oder ein Produktions- und Qualitäts-Dashboard, das Maschinendaten mit kaufmännischen Kennzahlen verbindet.
Der Vorteil dieses Vorgehens: Ein klar umrissener erster Anwendungsfall liefert schnell sichtbaren Wert, schafft Akzeptanz im Unternehmen und hält den Aufwand überschaubar. Snowflakes elastisches Modell unterstützt das ideal – Sie können klein beginnen und wachsen, ohne anfangs in große Infrastruktur investieren zu müssen.
Steht der erste Use-Case, geht es an die Daten. In den meisten Fällen müssen Daten aus den Quellsystemen regelmäßig nach Snowflake geladen werden. Hier kommen spezialisierte Integrationswerkzeuge ins Spiel, die Standardquellen wie gängige ERP- und CRM-Systeme, Datenbanken und Online-Dienste anbinden und die Daten zuverlässig in Snowflake bereitstellen. Direkt in Snowflake werden die Rohdaten anschließend in saubere, dokumentierte Analysetabellen modelliert – ein Schritt, der über die spätere Datenqualität entscheidet.
Wer von einem bestehenden, klassischen Data Warehouse migriert, sollte den Aufwand nicht unterschätzen: SQL-Dialekte unterscheiden sich, gewachsene Logik muss überprüft und oft neu strukturiert werden, und nicht jede alte Berechnung verdient es, eins zu eins übernommen zu werden. Eine Migration ist immer auch eine Chance, Altlasten zu bereinigen. Wir empfehlen ein schrittweises Vorgehen pro Datenbereich statt eines riskanten Big-Bang-Umzugs.
Der dritte Erfolgsfaktor ist Governance – und zwar von Beginn an, nicht als nachträgliche Reparatur. Dazu gehört ein durchdachtes rollenbasiertes Rechtekonzept, das festlegt, wer welche Daten sehen und welche Warehouses nutzen darf. Dazu gehören klare Namens- und Strukturkonventionen für Datenbanken, Schemata und Warehouses, damit die Plattform nicht im Wildwuchs endet. Und dazu gehört die bereits beschriebene Kostensteuerung mit Resource Monitors, Budgets und Monitoring.
Gerade im Mittelstand, wo oft wenige Personen viele Rollen tragen, ist diese Struktur entscheidend, damit die Plattform auch nach dem ersten Projekt wartbar und sicher bleibt. Snowflake macht den technischen Betrieb einfach – die organisatorische Disziplin müssen Sie selbst mitbringen. Genau an dieser Schnittstelle zwischen Technik, Daten und Organisation setzt unsere Beratungsarbeit an.
