Gestione dei costi Snowflake nel 2026: cosa è cambiato davvero (recap del webinar)

• La piattaforma Snowflake si è espansa ben oltre compute e storage, e ogni nuovo servizio è un nuovo punto in cui i costi possono annidarsi.
• Le funzioni AI Cortex di Snowflake sono potenti, ma sono anche il modo più facile per bruciare migliaia di dollari per errore. Un cliente ha speso 60.000 $ in tre giorni per una query che doveva girare in QA e invece è finita in produzione.
• La visibilità deve venire prima dell'ottimizzazione. I team continuano a scoprire workloads da centinaia di migliaia di dollari l'anno di cui nessuno conosceva l'esistenza.
• Gli interventi con il ROI più alto sono di solito semplici: eseguire i job meno spesso e fare right-sizing dei warehouse, non riscrivere le query.
• Scalare la gestione dei costi in un'organizzazione in crescita significa dare a ogni team la propria visibilità, non far passare ogni domanda sui costi da un unico team centrale.

Un tempo Snowflake significava compute e storage. Oggi il quadro è molto più ampio. Ian e Dave hanno passato in rassegna la lista crescente di servizi che i clienti eseguono ormai sulla piattaforma: app native, app Streamlit, modelli di machine learning distribuiti su compute pool, un set di funzionalità AI in rapida espansione e perfino workloads Postgres dopo l'acquisizione di Crunchy Data da parte di Snowflake.

Ognuno di questi compare come una nuova voce in fattura. E questo crea un vero problema di tracciamento: se il sistema di monitoraggio non sa che un nuovo servizio esiste, semplicemente non se ne vedranno i costi. SELECT ha un team di quasi 30 engineer dedicato esclusivamente a restare al passo con le release di Snowflake, così le nuove fonti di costo vengono supportate appena escono, non mesi dopo.

Dave ha aggiunto che non si tratta solo di una seccatura tecnica. La leadership prende sempre più spesso decisioni su dove devono girare i workloads, e non può farlo senza una reale trasparenza sui costi a supporto.

Le funzioni Cortex di Snowflake (oggi chiamate AI SQL) permettono di eseguire l'AI direttamente sui dati presenti in Snowflake. L'esempio di Dave: filtrare le recensioni di prodotto per isolare solo quelle in cui il cliente esprimeva frustrazione, con una singola query. Pochi anni fa significava far rivedere e taggare ogni record a mano.

Questa comodità comporta un rischio reale. Dave ha condiviso il caso di un cliente: una query con una funzione Cortex integrata doveva girare in QA. Invece è girata in produzione sull'intero dataset e ha bruciato 60.000 $ di token in tre giorni, senza produrre nulla di utilizzabile.

Ian ha spiegato perché succede così facilmente. L'uso dell'AI viene fatturato in base ai token in ingresso e in uscita. I token in ingresso sono più o meno prevedibili in anticipo, perché si può stimare la dimensione di ciò che si dà in pasto al modello. Quelli in uscita no, perché quanto genera il modello dipende dalla domanda stessa. È questa asimmetria a rendere i costi dell'AI così difficili da prevedere prima di lanciare qualcosa.

Come si ottiene visibilità sulla spesa AI in Snowflake?

Lo schema account usage di Snowflake include diverse viste dedicate all'AI. La maggior parte funziona come le altre viste di account usage, con l'utilizzo orario suddiviso per modello. La vista sull'uso di AI SQL è a livello di query: mostra il modello utilizzato e il testo della query, ma non il prompt. L'opzione più granulare è la tabella degli eventi di AI observability. Vi si accede tramite una table function anziché una vista standard e può mostrare i prompt che generano l'utilizzo. Tende a essere più lenta da interrogare e, per quanto ne sa Ian, non è persistente, il che rende più difficili le analisi su lunghi periodi.

I budget e le quote AI di Snowflake fermano davvero la spesa fuori controllo?

In gran parte sì, con una lacuna importante. I budget AI permettono di impostare un limite mensile di crediti per un account o per un gruppo di oggetti taggati, coprendo Cortex agents, Cortex search e le funzioni AI, e avvisano quando il limite viene superato. Le quote per utente vanno oltre e bloccano effettivamente l'utilizzo, anche se il blocco richiede qualche minuto per entrare in azione, invece di fermare la query all'istante.

La lacuna: una singola richiesta di grandi dimensioni può comunque sfondare il limite prima che il sistema reagisca. L'esempio di Ian era l'esecuzione in un colpo solo di una funzione di sentiment analysis su un'enorme tabella di recensioni. Si possono spendere 10.000 $, e solo la query successiva viene bloccata. Le quote intercettano comunque i casi ripetuti o quelli che durano un intero weekend, e Ian ha indicato la loro configurazione come la cosa da portarsi a casa dalla sessione. Ma non sostituiscono le buone pratiche, come testare in QA su dataset limitati prima di toccare la produzione.

Come si misura il ROI della spesa AI?

Non esiste una formula universale. Si parte dal lato misurabile con precisione, cioè il costo. Per il lato del valore dipende dal caso d'uso. Se l'AI sostituisce qualcosa che esisteva già, come un team che classificava manualmente il sentiment, si confronta il vecchio costo in tempo e compute con quello nuovo. Se abilita qualcosa di nuovo, di solito si lavora con proxy: tempo risparmiato, velocità di ticket o story da un sistema come Jira, o ricavi recuperati. Quando nessuno di questi dà una risposta chiara, il suggerimento di Ian è stato diretto: spegnerlo e vedere chi si lamenta.

Prima di qualsiasi lavoro di ottimizzazione bisogna sapere quanto costano davvero le cose. Ian ha raccontato di un cliente che, al primo accesso a SELECT, ha trovato in cima alla lista un workload da 850.000 $ l'anno, generato in gran parte da una funzione AI in esecuzione all'interno di quello che si è rivelato essere un job di QA. L'hanno spento. Nessuna indagine approfondita: è bastata la visibilità a far emergere la soluzione.

La versione di Dave della stessa lezione: un cliente che spendeva 10.000 $ l'anno solo per inviare un'email da Snowflake. È bastato uno sguardo al costo reale per spostare quel workload su una soluzione più economica. E sente dire di continuo "pensavo di averlo spento tre mesi fa" quando i clienti vedono per la prima volta i costi query per query e workload per workload.

Una volta ottenuta la visibilità, la domanda successiva è se un'ottimizzazione vale il tempo investito. Spendere una giornata di lavoro di engineering per risparmiare 500 $ di storage è un affare in perdita. Dedicare qualche ora per risparmiarne 20.000 è una scelta ovvia. Il consiglio di Ian: fare questo conto prima di iniziare e cogliere i quick win prima di riscrivere qualsiasi SQL.

Quali sono gli interventi a più alto ROI una volta che si sa dove guardare?

1. Eseguire i job meno spesso. Un job che gira ogni ora e costa 10.000 $ l'anno scende sotto i 500 $ l'anno se basta eseguirlo una volta al giorno: una riduzione del 96% con una sola modifica di configurazione. Anche passare da ogni ora a ogni tre ore fa risparmiare circa due terzi del costo.
2. Fare right-sizing del warehouse. Ogni aumento di taglia raddoppia compute e costo, quindi un warehouse più grande conviene solo se anche il tempo di esecuzione delle query si dimezza davvero. L'esempio di Ian: portare un warehouse di ingestion da Large a Extra Small ha fatto passare il tempo medio di query da circa cinque secondi a circa venti, un ritardo che nessuno ha notato, con un risparmio di 50.000 $ l'anno. Un'euristica utile è circa 125 partizioni scansionate per core CPU (un warehouse Large ha 64 core), quindi una query che scansiona solo 500 partizioni raramente ha bisogno di più di un Extra Small.
3. Attenzione al pattern "Snowflake come coda di messaggi". Dave ha visto team usare Snowflake come una coda Kafka, eseguendo milioni di piccolissime operazioni invece delle operazioni batch più grandi per cui è progettato. Così i warehouse restano accesi di continuo e i costi lievitano. Meglio abbinare il workload alla tecnologia giusta.
4. Valutare lo scaling orizzontale, non solo verticale. Dave ha fatto notare che spesso si sceglie una taglia di warehouse trascurando il numero di cluster. Aumentare il numero di cluster può dare risultati migliori del semplice aumento della taglia del warehouse, a seconda del workload.
5. Usare agenti AI di coding per le riscritture più complesse. L'esempio interno di SELECT citato da Ian: un dataset ricreato da zero a ogni esecuzione costava oltre 8.000 $ l'anno, e poche ore dedicate a rendere la query incrementale hanno eliminato quella spesa. Ha aggiunto che agenti di coding come Coco oggi rendono possibile questo tipo di riscrittura in poche ore, dove prima servivano giorni.

Sull'ingestion in particolare, Ian ha detto che di solito pesa intorno al 10-20% della spesa di compute, e la quota è in calo. Snowpipe Streaming ha ridotto i costi di ingestion di circa 10 volte per alcuni clienti, e anche l'adozione di Iceberg aiuta. I due risparmi più facili sull'ingestion secondo Dave: importare solo le tabelle e le colonne davvero necessarie e allineare la frequenza di aggiornamento al reale bisogno di business, invece di puntare per default al quasi real time.

I team stanno spostando workloads verso engine più economici come DuckDB o adottando Iceberg per risparmiare?

Su piccola scala, a volte. Un singolo engineer in un'azienda più piccola può ragionevolmente indirizzare workloads specifici verso qualcosa come DuckDB. Su larga scala, con migliaia di utenti che richiedono controlli di accesso centralizzati, è raro, perché diventa troppo difficile da gestire. Dave ha detto di non aver mai davvero considerato Iceberg come una leva di risparmio. Il suo punto di forza è l'interoperabilità: si possono riutilizzare gli stessi dati da più ambienti senza spendere altro compute. Ian ha aggiunto che Iceberg può ridurre i costi di ingestion ed evita di pagare lo storage due volte, ma farci girare sopra più engine di compute non è qualcosa che vede spesso. Dave ha detto che ciò che osserva più di frequente sono clienti che spostano interi workloads tra piattaforme, ad esempio da Snowflake a Databricks o da Postgres a Snowflake e ritorno, in base a quale si adatta meglio al caso d'uso. Per lui si tratta di risparmiare compute, più che di ottimizzare lo storage.

Un unico team dati centrale che risponde a ogni domanda sui costi non scala. Dave, che ha vissuto quel ruolo in prima persona, ha descritto come un piccolo team diventa un collo di bottiglia quando ogni richiesta sui dati passa da lì. La soluzione è dare agli utenti finali visibilità sui costi che generano, così che ognuno possa gestire in modo responsabile ciò che spende.

Si parte dall'allocazione dei costi: mappare la spesa sui team che ne sono responsabili, così l'attenzione di ciascuno resta su ciò che può controllare. Interlocutori diversi hanno poi bisogno di viste diverse. I dirigenti vogliono in genere dashboard di alto livello con i costi per gruppo su un giorno, una settimana o un mese. I practitioner vogliono vedere nello specifico ciò che il proprio team sta eseguendo.

Rendere queste informazioni facilmente accessibili conta quanto averle. Dave ha suggerito di costruire dashboard pertinenti per ogni tipo di pubblico, o di dare alle persone accesso a un server MCP in modo che possano porre a Claude le domande giuste. Ian ha aggiunto che a volte gli utenti hanno semplicemente bisogno di informazioni curate in una UI facile da usare: portatemele voi, non costringetemi ad andarle a cercare.

Un center of excellence ha un ruolo reale, ma circoscritto. Il team centrale dovrebbe consigliare gli utenti su come migliorare i propri costi e diffondere quella conoscenza in tutta l'organizzazione, non assumersi la responsabilità di eseguire ogni ottimizzazione in prima persona. Come ha detto Ian, fare queste cose una per una per conto dell'intera organizzazione può portare solo fino a un certo punto.