Kann man Snowflake on-premise betreiben?

Wer sie stellt, meint selten die Software. Gemeint ist: Können unsere Daten in unserem Rechenzentrum liegen, unter unserer Kontrolle, ohne dass ein Anbieter dazwischensteht? Snowflake hat auf diese Frage über die Jahre mehrere Antworten gegeben. Keine davon ist ein Ja, und eine davon wird regelmäßig für eines gehalten.

Die kurze Antwort

Snowflake lässt sich nicht im eigenen Rechenzentrum betreiben — in keiner Edition, in keiner Ausbaustufe. Das Produkt ist als Dienst gebaut: Rechenknoten und Speicher liegen bei einem Hyperscaler, die Steuerungsebene betreibt Snowflake. Beides ist nicht als auslieferbare Software vorgesehen.

Was es stattdessen gibt

Es gibt eine Leiter der Abschottung, und sie ist länger, als viele wissen:

Warum „Bring Your Own Cloud“ nicht heißt, was man denkt

Der Name ist präzise und wird trotzdem missverstanden. Snowflakes eigene Dokumentation beschreibt es so: die Datenebene von Openflow läuft in der eigenen Cloud-Umgebung, während Snowflake den Dienst insgesamt und die Steuerungsebene verwaltet. Zwei Einschränkungen stecken in diesem Satz, und beide zählen.

• „Eigene Cloud“ heißt eigenes Konto bei AWS — nicht eigenes Gebäude. Der Unterschied ist der ganze Punkt der Frage.
• Es geht um Openflow, also um die Ingestion. Das Warehouse, in das diese Leitungen laufen, bleibt bei Snowflake.

Man verlagert also die Rohre, nicht das Becken. Für Datenschutz-Vorbehalte bei der Vorverarbeitung ist das ein echter Gewinn — sensible Felder lassen sich im eigenen Netz maskieren, bevor sie den Bereich verlassen. Für die Frage, wo die Daten am Ende liegen, ändert es nichts.

Wo die Linie tatsächlich verläuft

Die Leiter oben misst Abschottung, nicht Hoheit. Selbst die höchste Stufe ist eine dedizierte Instanz, die Snowflake für einen betreibt, in der Infrastruktur eines Hyperscalers. Getrennt von anderen Kunden — ja. Unter eigener Kontrolle — nein. Die Linie verläuft nicht zwischen geteilt und dediziert, sondern zwischen „jemand betreibt es für mich“ und „ich betreibe es“.

Das ist kein Vorwurf. Ein verwalteter Dienst nimmt einem Arbeit ab, für die man sonst Leute braucht, und Snowflake ist darin gut. Es ist nur eine andere Antwort auf eine andere Frage.

Wenn die Anforderung wirklich das eigene Rechenzentrum ist

Dann führt kein Weg über Snowflake, sondern an ihm vorbei. Zwei Familien kommen infrage, und sie unterscheiden sich stärker voneinander als von Snowflake:

• Kommerzielle Warehouses mit On-Prem-Herkunft: Teradata, Vertica, IBM Db2 Warehouse, Exasol. Ausgereift, mit Vertrieb, Support und Lizenzmodell — und meist ohne veröffentlichte Preise.
• Engines und Lakehouse-Bausteine, die man selbst zusammensetzt: ClickHouse, Trino auf Apache Iceberg, Dremio, IOMETE. Offene Formate, mehr Freiheit, mehr eigene Arbeit.

Der Preis für beide Wege ist derselbe und wird in TCO-Vergleichen regelmäßig unterschlagen: Man übernimmt den Betrieb. Patches, Kapazitätsplanung, Rufbereitschaft, jemand, der versteht, warum eine Abfrage seit Dienstag langsam ist. Wer das nicht einplant, rechnet sich den Wechsel schön.

Die Frage vor der Frage

Bevor man Produkte vergleicht, lohnt es, die Anforderung zu zerlegen. Hinter „on-premise“ stecken meist drei verschiedene Dinge, und sie haben verschiedene Antworten:

1. 1Datenlage: Die Daten müssen in einem bestimmten Land liegen. Das erfüllt eine EU-Region — dafür braucht es kein eigenes Rechenzentrum.
2. 2Rechtshoheit: Kein Zugriff durch fremde Behörden. Der Standort allein klärt das nicht; entscheidend ist, wer über den Betreiber verfügen kann.
3. 3Kostenkontrolle: Keine Rechnung, die mit der Nutzung wächst. Das ist eine wirtschaftliche Frage und hat mit dem Standort nichts zu tun.

Wer nur das erste braucht, kommt mit einer Region weiter als mit einem Umzug. Wer das zweite oder dritte meint, wird von der Abschottungsleiter nicht bedient, egal wie weit oben man einsteigt. Das zu trennen, spart in der Praxis mehr Zeit als jeder Produktvergleich.