TL;DR
- Die Container Runtime ist mein Standard für das Hosting von Streamlit in Snowflake. Dashboards bleiben vorgewärmt und bieten die beste User Experience.
- Ein Container-Runtime-Node kostet 0,11 Credits pro Stunde, verglichen mit 1 Credit pro Stunde für ein XS Warehouse. Bei $3 pro Credit sind das rund $238 pro Monat im Dauerbetrieb. Ein Node hostet drei Dashboards. Das vierte startet einen neuen Node.
- Noch mehr sparen Sie, wenn Sie den Compute Pool per nächtlichem Task suspendieren. Der Kompromiss: Wer morgens ein Dashboard oder eine App als Erster öffnet, wartet rund 45 Sekunden.
- Nach einem Suspend verursachen nur die Dashboards wieder Kosten, die tatsächlich geöffnet werden. Sie zahlen für das, was genutzt wird – nicht für das, was deployt ist.
- Für den Preis von 100 Power-BI-Premium-Per-User-Lizenzen ($2.400 pro Monat) kann Snowflake mit dem nächtlichen Suspend rund 81 aktiv genutzte Streamlit-Apps hosten.
Einleitung
Streamlit ist eine Open-Source-Python-Bibliothek für datenzentrierte Web-Apps und Dashboards. Sie schreiben Python und erhalten Charts, Filter, Buttons, Modals und Interaktivität – ohne eine Zeile HTML oder JavaScript. Dieser Python-only-Ansatz hat Streamlit zu einem äußerst beliebten Werkzeug für Datenteams gemacht, um interne Tools auszuliefern.
Snowflake hat Streamlit 2022 übernommen, und Streamlit in Snowflake ist das Ergebnis. Ihre App läuft direkt in Ihrem Snowflake-Account, unmittelbar neben Ihren Daten. Es gibt keinen Server zu hosten, kein separates Login-System und kein Kopieren von Daten an andere Orte. Der Zugriff folgt denselben Rollen, die Sie ohnehin schon verwalten.
Inzwischen gibt es zwei Möglichkeiten, eine Streamlit-App in Snowflake zu betreiben – und sie werden sehr unterschiedlich abgerechnet. Wählen Sie die falsche oder lassen Sie die richtige über Nacht laufen, zahlen Sie drauf.
Dieser Beitrag zeigt, wie jede Option abgerechnet wird, eine Auto-Suspend-Falle, die mich echte Credits gekostet hat, wie Sie nächtlich suspendieren, was das mit Ihrer Rechnung macht (mehr, als Sie vermuten würden) und wo der Break-even gegenüber Power BI liegt.

Zwei Wege, Streamlit in Snowflake zu betreiben
Warehouse Runtime
Die App läuft auf einem Virtual Warehouse. Abgerechnet wird die Zeit, in der das Warehouse aktiv ist. Jedes Mal, wenn sich ein Nutzer verbindet, startet darin ein neuer Streamlit-Server-Prozess, und ein Websocket hält das Warehouse wach – bis etwa 15 Minuten nach der letzten Aktivität des Nutzers. Das Timeout ist konfigurierbar, Sie können es also problemlos auf 5 Minuten Inaktivität setzen. Ein XS Warehouse verbraucht 1 Credit pro Stunde, solange es wach ist. Ihre SQL-Abfragen könnten auf einem separaten Query Warehouse laufen, sodass unter Umständen zwei Warehouses Credits verbrauchen.
Container Runtime
Die App läuft auf einem Node in einem Compute Pool, den Snowflake für Sie verwaltet. Der Streamlit-Server läuft dort durchgehend, Seiten laden also schnell, und alle Nutzer teilen sich denselben Server. Das ist tatsächlich die beste User Experience, da kaum ein Nutzer je einen Cold Start erlebt.
Snowflake unterstützt beides und macht die Container Runtime zum Standard für neue Apps.
Meine Einschätzung: Eine Warehouse Runtime mit striktem 5-Minuten-Timeout zum Geldsparen ist eine schlechte User Experience, denn fast jeder Besucher bekommt einen Cold Start. Ich nutze für alle meine Streamlit-Apps die Container Runtime, damit die Dashboards vorgewärmt und gecacht sind, sobald der erste Nutzer die Seite aufgerufen hat.
Gleicher Streamlit-Code. Sehr unterschiedliche Rechnung.
Wählen Sie die kleinstmögliche Compute-Größe für den Streamlit-Prozess
Ob Warehouse Runtime oder die neue Standard-Container-Runtime: Der Streamlit-Prozess selbst braucht nicht viel Rechenleistung. Ein Extra-Small-Gen-1-Warehouse reicht für jede Streamlit-App, die mir bisher begegnet ist. Die Abfragen selbst können ein größeres Warehouse nutzen – aber verschwenden Sie keine Credits auf den Streamlit-Prozess.
Wenn Sie das Dashboard auf Ihrem Laptop entwickeln können, können Sie es auf einem Extra Small oder dem Standard-Compute-Pool hosten, der mit CPU_X64_S läuft.
So wird die Container Runtime abgerechnet
Ein Node ist eine Abrechnungseinheit. Auf dem Standard-System-CPU-Pool packt Snowflake drei Dashboards auf einen Node. Läuft ein viertes Dashboard, startet ein zweiter Node. Ein siebtes startet einen dritten. Der Pool wächst in Dreierschritten. (Weitere Beispiele finden Sie im Abschnitt Kostenszenarien weiter unten.)
Der kleinste Node kostet rund 0,11 Credits pro Stunde. Das ergibt:
- 2,64 Credits pro Tag
- rund 79 Credits pro Monat
- $7,92 pro Tag bzw. $237,60 pro Monat bei $3 pro Credit, falls Auto-Suspend nie greift.
Ihr Credit-Preis wird abweichen, setzen Sie also Ihren eigenen ein. Ich rechne in allen Beispielen unten mit $3.
Ein paar Punkte, die auffallen:
- Der Preis ist derselbe für 1 Nutzer oder 100 Nutzer. Dem Node ist das egal. (Der Vergleich mit der Power-BI-Per-User-Lizenzierung folgt unten!) Ein erfrischendes Preismodell – ich bin BI-Lizenzen mit Kosten pro Nutzer so leid.
- Ein Node ist pro Stunde rund 9x günstiger als ein XS Warehouse. Der Haken: Der Node bleibt an, das Warehouse nicht. Wäre ein Code-Warehouse mehr als etwa 2,6 Stunden am Tag wach, gewinnt der Node. Wird Ihr Dashboard zweimal pro Woche geöffnet, gewinnt das Warehouse.
- Ein Dashboard, das niemand geöffnet hat, kostet nichts. Der Service der App startet beim ersten Aufruf. Wer 25 Dashboards deployt, mietet nicht automatisch 9 Nodes. Nur die geöffneten zählen.
- An Ihren Query-Kosten ändert die Container Runtime nichts. Das SQL läuft weiterhin auf einem Warehouse. Dieser Beitrag behandelt nur die Hosting-Kosten der App.
Ich habe sehr gute Erfahrungen mit der Container Runtime für Streamlit in Kombination mit Adaptive Warehouses für die Query-Ausführung gemacht. Laut Snowflake-Doku sind Adaptive Warehouses schneller als Gen-2-Warehouses.
Wie viele Nodes laufen in meinem Streamlit Compute Pool?
Streamlit-Apps werden auf den Standard-Compute-Pool system_compute_pool_cpu deployt. Wie viele Nodes laufen, sehen Sie in der UI unter Compute in der Seitenleiste, dann Compute Pools.

Wenn Sie auf die Zeile klicken, gelangen Sie auf eine Detailseite, auf der Sie sehen, welche Apps laufen:

Wer lieber Code nutzt, führt Folgendes aus:
show compute pools like 'SYSTEM_COMPUTE_POOL_CPU';Prüfen Sie anschließend die Spalte active_nodes.

Die Auto-Suspend-Falle
Die Doku sagt Folgendes: Nach drei Tagen ohne Nutzeraktivität endet der Streamlit-Server-Prozess. Danach suspendiert der Compute Pool gemäß seinem eigenen AUTO_SUSPEND-Wert.
Damit gibt es zwei Probleme.
Erstens: Die drei Tage sind (noch) nicht konfigurierbar. Sie können daraus weder einen Tag noch eine Stunde machen. Drei Tage leerlaufender Node sind rund 8 Credits oder $24. Für sich genommen kein Desaster. Aber es summiert sich über einen ganzen Pool hinweg – und über jede Umgebung, in die Sie deployen.
Zweitens: Der AUTO_SUSPEND des Pools zählt erst, wenn keine Services mehr darauf laufen. Der Streamlit-Service bleibt bestehen, bis die drei Tage um sind, der Pool-Timer kommt also nie zum Zug.
Stand 15. Oktober 2026 greift Auto-Suspend nicht zuverlässig: Ich habe beobachtet, wie ein Service samt Container über Tag 3 hinaus lief und an Tag 4 immer noch Geld kostete. Laut Snowflake-Support liegt die Ursache in offen gelassenen Browser-Tabs, die den Websocket immer wieder neu aufbauen wollen (selbst abgelehnte 401-Reconnects setzen den Idle-Timer im Backend zurück). Snowflake arbeitet an einem Fix – wenn Sie das hier lesen, ist das Problem womöglich schon behoben.
Es gibt ein Private-Preview-Feature, das idle_auto_shutdown_time_seconds auf App-Ebene hinzufügt, so wie es die Warehouse Runtime bereits hat. Vielleicht ist Ihnen die Property schon aufgefallen, wenn Sie eine Streamlit-App per describe abfragen. Sobald Sie freigeschaltet sind, können Sie einen kürzeren Wert setzen. Fragen Sie Ihr Snowflake-Account-Team. Ich würde das liebend gern pro App auf ein paar Stunden setzen und das schlankstmögliche Setup fahren!
Bis dahin gilt: Verlassen Sie sich nicht auf den Drei-Tage-Timer. Suspendieren Sie selbst, wenn Sie sparen wollen. Schauen wir uns das genauer an.
Nächtlich suspendieren und die Nutzer aufwecken lassen
Die einfachste Kostenersparnis ist ein geplanter Task, der den Pool jeden Abend suspendiert:
CREATE OR REPLACE TASK suspend_streamlit_pool SCHEDULE = 'USING CRON 30 18 * * * America/New_York'AS ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU SUSPEND;Die Rolle, der der Task gehört, braucht OPERATE auf dem Pool. Läuft er als Serverless Task, braucht sie zusätzlich EXECUTE MANAGED TASK.
Morgens muss niemand etwas tun. Die erste Person, die ein Dashboard öffnet, weckt den Pool auf. Nach meiner Erfahrung dauert dieser erste Aufruf rund 45 Sekunden (Cold Start). Danach ist es für alle anderen schnell.
Der Punkt, den viele übersehen – und wo sich die Ersparnis summiert
Wenn Sie den Pool nachts suspendieren, wird jedes Dashboard heruntergefahren. Am Morgen kommen nur die zurück, die jemand öffnet – und nur diese kosten wieder Geld.
Angenommen, Sie haben 25 Dashboards. Lassen Sie alles laufen, zahlen Sie für 9 Nodes, denn mit der Zeit öffnet jemand jedes einzelne davon. Suspendieren Sie nachts und öffnen die Leute am nächsten Tag nur 4 Dashboards, zahlen Sie für 2 Nodes. Die anderen 21 Dashboards kosten an diesem Tag nichts.
Das macht den nächtlichen Suspend zu einem deutlich mächtigeren Hebel, als nur die suspendierten Nachtstunden einzusparen. Sie zahlen auch nicht mehr für Dashboards, die niemand ansieht. Monatsabschluss-Reports, das Quartals-Review, das verwaiste Dashboard aus einem Projekt von vor Monaten: Sie kosten nur an den Tagen Geld, an denen sie tatsächlich jemand öffnet.
Ihre Rechnung richtet sich jetzt danach, wie viele Dashboards pro Tag geöffnet werden – nicht danach, wie viele Sie deployt haben.
Vorteile
- Planbare Rechnung. Sie kennen den Worst Case.
- Es funktioniert auch, solange der Auto-Suspend-Bug existiert.
- Ein einziges Statement suspendiert jeden Node im Pool, egal ob Sie 3 Dashboards haben oder 30.
- Selten genutzte Dashboards kosten kein Geld mehr.
- Nichts, woran man denken muss. Niemand muss sich einloggen und etwas stoppen.
Nachteile
- Wer ein Dashboard an einem Tag als Erster öffnet, wartet rund 45 Sekunden. Meine Nutzer kommen damit gut klar.
- Wer spät oder am Wochenende arbeitet, trifft auf denselben Cold Start.
- Der Suspend fährt jeden Node im Pool herunter. Wer gerade mitten in einer Session ist, landet plötzlich auf einer Reboot-Seite – wählen Sie also eine Uhrzeit, zu der alle Feierabend haben. Meiner Meinung nach ist das Risiko gering und der Refresh schnell genug, dass es sich lohnt.
Wenn 45 Sekunden zu lang sind für die Leute, die morgens als Erste die Dashboards öffnen, können Sie ein paar Minuten vor deren Ankunft eine authentifizierte Anfrage an die Endpunkte dieser Apps senden. Bei mir hat das funktioniert, erfordert aber ein OAuth-Setup, was zusätzliche Komplexität bedeutet. Wärmen Sie nur die wenigen wichtigen vor, sonst verspielen Sie die Ersparnis bei den Dashboards, die niemand liest. Für mich ist das Vorwärmen (wegen des nötigen OAuth-Flows) mehr Aufwand, als es wert ist – aber die Option existiert.
Kostenszenarien
Annahmen: $3 pro Credit, 25 deployte Dashboards, drei Dashboards pro Node. "Suspendiert" heißt: Die Nodes laufen nur werktags 12 Stunden am Tag (22 Tage im Monat). Das ist eine Obergrenze, denn ein um 14 Uhr geöffnetes Dashboard kostet für den Vormittag nichts.

Vergleichen Sie das nun damit, alle 25 rund um die Uhr laufen zu lassen. Mit der Zeit wird jedes Dashboard geöffnet, Sie zahlen also den ganzen Monat für 9 Nodes: $2.138. Werden an einem typischen Tag nur 4 Dashboards genutzt, bringt Sie der nächtliche Suspend von $2.138 auf $174.
Packen Sie Ihre Nodes voll. Dashboard Nummer 4 kostet Sie dasselbe wie Dashboard Nummer 6 – wenn Sie also schon für einen zweiten Node zahlen, füllen Sie ihn auch.
Break-even vs. Power BI
Power BI Pro wird pro Nutzer abgerechnet. Beim Listenpreis von $14 pro Nutzer und Monat braucht jede Person, die einen Report ansieht, eine Lizenz. Streamlit in Snowflake wird pro Node abgerechnet. Es gibt keine Plattformgebühr und keine Lizenzgebühr pro Nutzer.
Starten Sie also bei Ihrer Nutzerzahl. Hier sehen Sie, was Power BI bei $24 pro Nutzer und Monat (Premium) kostet – und wie viele Dashboards Snowflake mit dem nächtlichen Suspend für dasselbe Geld betreibt:

Lesen Sie die Tabelle so: Werden 4 Dashboards von 50 Personen genutzt, kostet Power BI Pro rund $700 im Monat und Snowflake $174. Werden alle 25 Dashboards von 40 Personen genutzt, liegt Power BI bei rund $560 und Snowflake bei $784 – oder $2.138, wenn Sie nie suspendieren. Je mehr Personen pro Dashboard, desto besser schneidet Snowflake ab. Je mehr Dashboards pro Person, desto besser Power BI.
Zwei ehrliche Einschränkungen:
- Streamlit ist Code. Power BI ist Drag-and-Drop. Wenn Ihre Analysten kein Python schreiben können (oder nicht voll KI-unterstützt arbeiten), spielen die Hosting-Einsparungen womöglich keine Rolle.
- Power BI Premium Per User kostet $24 pro Nutzer und Monat, und mit Fabric-Kapazität entfällt die Viewer-Lizenz bei großen Deployments – sie startet aber bei rund $5.000 im Monat. Prüfen Sie aktuelle Preise, bevor Sie den Business Case aufstellen.
Fazit
- Nutzen Sie die Container Runtime für Dashboards, die häufig geöffnet werden. Sie ist mein neuer Standard – ich bevorzuge die günstigeren Stundenkosten und will sie nicht mit meiner Warehouse-Nutzung vermischen. Außerdem gefällt mir die User Experience mit weniger Cold Starts im Vergleich zu aggressiv auto-suspendierten Warehouses.
- Drei Dashboards pro Node. Das vierte startet einen neuen Node.
- Der kleinste Node kostet rund 0,11 Credits pro Stunde, 2,64 pro Tag, rund $238 im Monat bei $3 pro Credit. Ja, der kleinste Node kann Ihre Dashboards problemlos hosten. Die Datenmenge spielt keine Rolle; Abfragen laufen weiterhin auf Virtual Warehouses.
- Verlassen Sie sich nicht auf den Drei-Tage-Auto-Suspend. Suspendieren Sie den Pool nach Zeitplan.
- Nach einem Suspend kosten nur die Dashboards wieder Geld, die jemand öffnet. Sie zahlen für das, was genutzt wird – nicht für das, was deployt ist.
- Planen Sie einen Cold Start von 45 Sekunden ein – und sagen Sie Ihren Nutzern Bescheid.
- Ab ein paar Dutzend Nutzern schlägt die Abrechnung pro Node die Abrechnung pro Lizenz.
Wenn Sie Unterstützung bei der Dimensionierung eines Streamlit-Setups brauchen oder herausfinden wollen, wohin Ihre Snowflake-Credits fließen, freuen wir uns, von Ihnen zu hören. Melden Sie sich gern!