Dashboard Streamlit in Snowflake: le best practice per l'hosting

L'insidia dell'auto-suspend

Ecco cosa dice la documentazione. Dopo tre giorni di inattività degli utenti, il processo del server Streamlit termina. Poi il compute pool si sospende secondo il proprio valore di AUTO_SUSPEND.

Due problemi.

Primo: i tre giorni non sono configurabili, per ora. Non puoi ridurli a un giorno o a un'ora. Tre giorni di nodo inattivo sono circa 8 crediti, ovvero $24. Non un disastro di per sé. Ma si accumula su tutto il pool, e su ogni ambiente in cui fai il deploy.

Secondo: l'AUTO_SUSPEND del pool inizia a contare solo quando non ci sono servizi in esecuzione. Il servizio Streamlit resta lì finché i tre giorni non scadono, quindi il timer del pool non ha mai occasione di aiutarti.

Al 15 ottobre 2026, l'auto-suspend non scatta in modo affidabile: ho visto un servizio e il suo container superare il terzo giorno e continuare a generare costi anche il quarto, e il supporto Snowflake mi ha detto che la causa sono le schede del browser lasciate aperte che continuano a ritentare il websocket (anche le riconnessioni rifiutate con 401 azzerano il timer di inattività sul backend). Snowflake sta lavorando a una correzione, quindi quando leggerai questo articolo il problema potrebbe essere già risolto.

Esiste una funzionalità in private preview che aggiunge idle_auto_shutdown_time_seconds a livello di app, come già avviene nel warehouse runtime. Potresti aver visto comparire la proprietà facendo describe di un'app Streamlit. Una volta ottenuto l'accesso, potrai impostarla su un valore più breve. Chiedi al tuo account team Snowflake. Mi piacerebbe poterla impostare a poche ore per ogni app e avere la configurazione più snella possibile!

Fino ad allora, non contare sul timer di tre giorni. Sospendi tu stesso il pool se vuoi risparmiare. Vediamolo più nel dettaglio.

Sospendi ogni notte e lascia che siano gli utenti a risvegliare il pool

Il risparmio più semplice è un task pianificato che sospende il pool ogni sera:

CREATE OR REPLACE TASK suspend_streamlit_pool
  SCHEDULE = 'USING CRON 30 18 * * * America/New_York'
AS
  ALTER COMPUTE POOL SYSTEM_COMPUTE_POOL_CPU SUSPEND;

Il ruolo proprietario del task deve avere OPERATE sul pool. Se lo esegui come task serverless, serve anche EXECUTE MANAGED TASK.

Al mattino nessuno deve fare niente. La prima persona che apre una dashboard lo risveglia. Nella mia esperienza, quel primo caricamento è un cold start di circa 45 secondi. Dopodiché è veloce per tutti gli altri.

L'aspetto che sfugge a molti, ed è qui che i risparmi si accumulano

Quando sospendi il pool di notte, tutte le dashboard vengono spente. Al mattino tornano attive solo quelle che le persone aprono, e solo quelle ricominciano a generare costi.

Supponiamo che tu abbia 25 dashboard. Se lasci tutto acceso, paghi 9 nodi, perché col tempo qualcuno le apre tutte. Se sospendi di notte e il giorno dopo vengono aperte solo 4 dashboard, paghi 2 nodi. Le altre 21 dashboard quel giorno non costano nulla.

Questo rende la sospensione notturna un trucco molto più potente del semplice risparmio sulle ore notturne di sospensione. Smetti anche di pagare per le dashboard che nessuno guarda. I report di fine mese, la review trimestrale, la dashboard ormai datata che qualcuno ha costruito mesi fa per un progetto: costano solo nei giorni in cui qualcuno le visualizza davvero.

La tua bolletta ora segue quante dashboard vengono aperte al giorno, non quante ne hai deployate.

Pro

• Bolletta prevedibile. Conosci il caso peggiore.
• Funziona anche finché esiste il bug dell'auto-suspend.
• Una sola istruzione sospende tutti i nodi del pool, che tu abbia 3 dashboard o 30.
• Le dashboard usate raramente smettono di costare.
• Niente da ricordare. Nessuno deve accedere e fermare tutto manualmente.

Contro

• Il primo utente di ogni dashboard, ogni giorno, attende circa 45 secondi. Per i miei utenti va bene così.
• Chi lavora fino a tardi o nel weekend incontra lo stesso cold start.
• La sospensione spegne tutti i nodi del pool. Chi ha una sessione in corso si ritroverà all'improvviso davanti a una pagina di riavvio, quindi scegli un orario in cui le persone sono già andate a casa. Secondo me il rischio è basso e il refresh è abbastanza rapido da renderlo conveniente.

Se 45 secondi sono troppi per chi apre le dashboard come prima cosa al mattino, puoi inviare una richiesta autenticata agli endpoint di quelle app qualche minuto prima del loro arrivo. Per me ha funzionato, ma richiede la configurazione di OAuth, che aggiunge complessità. Pre-riscalda solo le poche che contano davvero, o finirai per vanificare i risparmi sulle dashboard che nessuno legge. Per me, il pre-warming delle dashboard è più complicato di quanto valga la pena (a causa del flusso OAuth necessario), ma l'opzione esiste.

Scenari di costo

Ipotesi: $3 per credito, 25 dashboard deployate, tre dashboard per nodo. "Sospeso" significa che i nodi girano 12 ore al giorno solo nei giorni feriali (22 giorni al mese). È un limite superiore, perché una dashboard aperta alle 14 non viene fatturata per la mattinata.

Ora confrontalo con il lasciare tutte e 25 accese 24 ore su 24. Col tempo ogni dashboard viene aperta, quindi paghi 9 nodi per tutto il mese: $2.138. Se in una giornata tipica vengono usate solo 4 dashboard, la sospensione notturna ti porta da $2.138 a $174.

Sfrutta al massimo i nodi. La dashboard numero 4 ti costa quanto la numero 6, quindi se devi comunque pagare un secondo nodo, riempilo.

Punto di pareggio rispetto a Power BI

Power BI Pro è fatturato per utente. Al prezzo di listino di $14 per utente al mese, ogni persona che visualizza un report ha bisogno di una licenza. Streamlit in Snowflake è fatturato per nodo. Nessun costo di piattaforma e nessuna licenza per utente.

Quindi parti dal numero di utenti. Ecco quanto costa Power BI a $24 per utente al mese (Premium), e quante dashboard fa girare Snowflake con la stessa cifra applicando la sospensione notturna:

Leggila così. Se 4 dashboard vengono usate da 50 persone, Power BI Pro costa circa $700 al mese e Snowflake $174. Se tutte e 25 le dashboard vengono usate da 40 persone, Power BI costa circa $560 e Snowflake $784, o $2.138 se non sospendi mai. Più persone per dashboard, più Snowflake è conveniente. Più dashboard per persona, più Power BI è conveniente.

Due doverose precisazioni:

• Streamlit è codice. Power BI è drag and drop. Se i tuoi analisti non sanno scrivere Python (o non sono pienamente supportati dall'AI), i risparmi sull'hosting potrebbero non contare.
• Power BI Premium Per User costa $24 per utente al mese, e la capacità Fabric elimina la licenza per i viewer nei grandi deployment, ma parte da circa $5.000 al mese. Verifica i prezzi attuali prima di costruire il business case.

Conclusioni

1. Usa il container runtime per le dashboard che le persone aprono di frequente. Il container runtime è il mio nuovo default: preferisco il costo orario inferiore e non voglio mescolarlo con l'utilizzo dei miei warehouse. Mi piace anche l'esperienza utente con meno cold start rispetto ai warehouse con auto-suspend aggressivo.
2. Tre dashboard per nodo. La quarta avvia un nuovo nodo.
3. Il nodo più piccolo costa circa 0,11 crediti all'ora, 2,64 al giorno, circa $238 al mese a $3 per credito. Sì, il nodo più piccolo può ospitare le tue dashboard senza problemi. La dimensione dei dati non conta; le query girano comunque sui Virtual Warehouse.
4. Non fare affidamento sull'auto-suspend di tre giorni. Sospendi il pool con una pianificazione.
5. Dopo una sospensione, solo le dashboard che vengono aperte ricominciano a generare costi. Paghi ciò che viene usato, non ciò che hai deployato.
6. Metti in conto un cold start di 45 secondi e avvisa i tuoi utenti.
7. Oltre qualche decina di utenti, la fatturazione per nodo batte quella per licenza.

Se vuoi aiuto nel dimensionare una configurazione Streamlit o nel capire dove finiscono i tuoi crediti Snowflake, ci farebbe piacere sentirti. Contattaci!