Snowflake Summit 2026: cosa è stato davvero rilasciato e cosa significa

Snowflake ha aperto i lavori con due rebranding che finiscono per toccare quasi tutti gli altri annunci. Cortex Code ora si chiama Coco. Snowflake Intelligence ora si chiama Cowork. Coco è pensato per sviluppatori e builder. Cowork è pensato per gli utenti business che vogliono risposte, non codice.

Quasi ogni altra funzionalità di questo recap gira su Coco o confluisce in Cowork. È il filo conduttore dell'intero evento.

OpenFlow diventa headless. OpenFlow estrae e carica dati in Snowflake, in concorrenza diretta con strumenti come Fivetran e orchestratori come Dagster. Jeff ha fatto notare che la UI di OpenFlow è sempre stata difficile da usare. La soluzione rilasciata da Snowflake è un modello a oggetti headless e programmabile che si può pilotare interamente tramite Coco: invece di cliccare in un'interfaccia confusa, si descrive ciò che si vuole e un agente lo costruisce.

Snowflake DataStream è Kafka su Snowflake. È wire-compatible con Kafka, quindi in teoria basta puntare i producer Kafka esistenti verso un nuovo URL Snowflake e i dati iniziano ad arrivare direttamente nelle tabelle, senza bisogno di bucket intermedi. Ian lo ha definito uno degli annunci più importanti dell'evento: elimina un'intera categoria di dipendenze da vendor esterni per l'ingestion in tempo reale, e funziona sia con le tabelle native Snowflake sia con le tabelle Iceberg.

Il data mirroring di Postgres potrebbe essere il singolo annuncio più importante per chi costruisce applicazioni. Basta attivare un'opzione e i dati Postgres compaiono automaticamente in Snowflake tramite change data capture, senza bisogno di pipeline ETL. La BI tradizionale lavora per definizione su dati non aggiornati: i caricamenti batch girano una volta all'ora o una volta al giorno, quindi tutto ciò che è accaduto nel sistema sorgente dopo l'ultimo caricamento non è ancora visibile. Questa novità colma quel divario nei casi d'uso in cui Postgres è il database operazionale. Ian la vede come la risposta di Snowflake al pattern ibrido transazionale-analitico per cui Unistore era stato originariamente creato, senza la complessità di dover mettere in piedi quell'architettura da soli.

Snowflake Postgres è arrivato in GA, insieme al supporto private link per gli account business-critical, alle chiavi gestite dal cliente e a una novità chiamata PGLake: un modo per usare Postgres stesso come catalogo Iceberg al posto di uno basato su JSON. Jeff la legge come una risposta diretta a DuckLake, che aveva fatto per prima una mossa simile come alternativa di catalogo.

Le migrazioni basate sull'AI promettono una riduzione dei tempi dell'88%. Né Ian né Jeff sono disposti a garantire quel numero. La lettura di Ian: "È marketing allo stato puro, un numero tirato fuori dal nulla per fare bella figura." Va preso come un segnale direzionale che la migrazione assistita dall'AI è più veloce, non come un numero su cui pianificare un budget.

Alcuni annunci di questa sezione si basano l'uno sull'altro, più che essere novità a sé stanti:

• Adaptive compute sta per passare in GA. È la mossa di Snowflake verso qualcosa di più vicino al modello di BigQuery, dove si pensa meno al dimensionamento dei warehouse. Il parere di Jeff, basato sul webinar di SELECT sull'argomento tenuto prima del Summit: c'è ancora un dimensionamento a cui pensare, ma questa è chiaramente la direzione in cui sta andando Snowflake, ed è probabile che diventi l'opzione di compute predefinita nel giro di qualche anno. Ian ha segnalato un avvertimento importante: diversi clienti hanno dato per scontato che l'adaptive compute sia una funzionalità di risparmio sui costi. Non lo è. È progettato per migliorare le performance senza tuning manuale, non per ridurre la fattura.
• Interactive workloads si basa su interactive tables e interactive warehouses, che esistono per competere con ClickHouse sull'analytics a bassa latenza. Questa release aggiunge in più miglioramenti su dimensionamento dei cluster, selezione delle chiavi e precaching.
• L'interactive compiler promette un'accelerazione di 40x sui tempi di compilazione. Jeff ha approfondito la questione e non è ancora del tutto certo se si applichi solo agli interactive workloads o a ogni query eseguita sui warehouse Snowflake standard. Le informazioni pubbliche sono abbastanza incoerenti da spingerci a segnalare l'incertezza invece di tirare a indovinare.
• L'ottimizzazione del motore Unistore è stata rilasciata insieme a queste novità, finora con meno dettagli pubblici.

La sintesi di Ian: interactive workloads e Unistore puntano dritti ai team che costruiscono esperienze veloci, in stile applicativo, sopra Snowflake. L'adaptive compute si rivolge a workloads ETL e BI più tradizionali, e riguarda le performance, non i costi.

AI Complete ora legge audio e video, non solo testo e immagini.

Cortex AI Function Studio (public preview) permette di creare funzioni Cortex personalizzate. Lo si punta su righe contenenti immagini, gli si chiede di segnalare quali mostrano un attributo specifico, e restituisce una funzione richiamabile come qualsiasi altra. I team di piattaforma possono validare la funzione prima di distribuirla su larga scala.

xAI entra nella lineup dei modelli, accanto ad Anthropic, OpenAI, Google, Meta, Mistral e DeepSeek. La notizia conta meno per Grok in sé e più per ciò che segnala: Snowflake si sta posizionando come livello di aggregazione sicuro per qualunque LLM si voglia usare, governato tramite le credenziali Snowflake esistenti invece di dover gestire chiavi API separate per ogni provider.

L'agentic search è facile da confondere con l'esistente Cortex Search. La distinzione: Cortex Search recupera frammenti di testo e risposte verbose da documenti non strutturati. L'agentic search è costruita per restituire una singola risposta deterministica, quindi una domanda come "quanti contratti sono datati 2025" restituisce un numero invece di una pila di estratti di contratti.

I code bundle permettono di eseguire Python come un semplice file .py. In precedenza, eseguire Python in Snowflake significava incapsularlo in una stored procedure SQL o lavorare in un notebook, e nessuna delle due opzioni supportava i normali flussi di debugging. Ora si carica un file Python in uno stage e lo si schedula direttamente. Ian ha sottolineato quanto tempo ci sia voluto: "Devo incapsularlo in quest'altro linguaggio per poterlo definire? Non è quello che volevo." Il requisito della stored procedure era una parte davvero macchinosa dell'esperienza di sviluppo, e rimuoverlo è importante per conquistare i team che vogliono semplicemente scrivere Python.

Sul fronte ML: Cortex Training (private preview) permette di fare fine-tuning di modelli open come Qwen e Mistral sui propri dati e, a quanto riportato, un modello molto più piccolo arriva a superare uno molto più grande una volta addestrato sul dataset specifico. Lo Snowflake Pipeline Builder aggiunge un'interfaccia drag-and-drop per costruire pipeline ML, simile nello spirito a strumenti come Alteryx, con Coco disponibile per aiutare a impostarle. Anche le estensioni VS Code e Cursor per il ML, oltre all'A/B testing online, sono passati in public preview.

Streamlit on Snowflake è arrivato in GA, e ora gira su un container runtime invece che su warehouse Streamlit dedicati. I container pool vengono fatturati a una frazione del credito orario di un warehouse completo, quindi questo dovrebbe ridurre in modo significativo il costo di esecuzione delle app Streamlit.

App Runtime risolve un problema reale: la discoverability. Jeff l'ha testato direttamente distribuendo la stessa app sia in Snowpark Container Services sia in App Runtime. La differenza funzionale è che le app in App Runtime compaiono in una scheda Apps dentro Snowsight, così le persone in tutta l'azienda possono effettivamente trovarle. Le app costruite direttamente in Container Services richiedono che qualcuno abbia già l'URL tra i preferiti, altrimenti nessuno le trova.

Snap and Ask permette di selezionare un grafico generato da Cowork e porre direttamente domande di approfondimento. Snowflake non lo ha mostrato dal vivo, quindi per ora non c'è molto altro da dire, se non tenerlo d'occhio nelle prossime release.

Iceberg v3 ha raggiunto la GA, e Snowflake rivendica il supporto v3 più ampio tra tutti i vendor Iceberg, incluso il supporto completo per insert, update, delete e merge atomici. Il catalogo REST di Iceberg rende inoltre possibili i flussi di lavoro cross-engine: si trasformano i dati in DuckDB e le modifiche compaiono in Snowflake attraverso il catalogo condiviso.

Lo storage Iceberg gestito da Snowflake è in GA su AWS, con Azure e GCP in arrivo a breve. Un cambiamento strutturale da conoscere, anche se non è finito su una slide in evidenza: la possibilità di creare e gestire un proprio catalogo Polaris sta scomparendo del tutto. Ora tutto passa per impostazione predefinita attraverso il catalogo Horizon, che esegue Polaris sotto il cofano senza mai esporre quel concetto all'utente. Si crea una tabella di tipo Iceberg, e compare automaticamente in Horizon.

La lettura di Ian sull'adozione di Iceberg in generale, basata sulla base clienti di SELECT: resta concentrata in due gruppi. Le aziende digital-native con dataset molto grandi e team di engineering solidi (pensate a Coinbase o Shopify), e le grandi imprese con l'organico tecnico necessario per gestirne la complessità. Gli investimenti continui di Snowflake in quest'area mirano ad abbassare quella barriera d'ingresso.

Durante il webinar è arrivata una domanda da Paul Horan: l'RBAC granulare (filtri sulle righe, mascheramento delle colonne) si estende al catalogo REST di Iceberg stesso, in modo che i consumer che usano qualcosa come Athena siano governati allo stesso modo degli utenti Snowflake? Né Ian né Jeff avevano una risposta sicura. L'esperienza di Jeff è stata di mantenere la governance dentro il livello Snowflake usando la REST API solo per lo spostamento dei dati, il che aggira la domanda invece di rispondervi. Sembra un vero problema aperto per chiunque cerchi di costruire un'architettura davvero multi-engine senza duplicare un livello di governance su ogni engine.

Altri aggiornamenti sul data sharing:

• Il data resharing ora include un flag che permette ai provider di decidere se i loro consumer possono ricondividere i dati a valle.
• L'open sharing permette di esporre dati a clienti non Snowflake tramite una REST API, senza che dall'altra parte serva un account Snowflake o un reader account.
• Anche le clean room hanno ricevuto aggiornamenti, anche se questo esula da ciò di cui Ian o Jeff si sentivano di parlare in dettaglio.
• L'ecosistema zero-copy si è esteso a SAP, Workday e IBM watsonx.data (si scrive proprio così, non è un refuso), affiancandosi all'integrazione esistente con Salesforce.

Su quest'ultimo punto, sia Ian sia Jeff hanno contestato un po' l'impostazione. Mettere in piedi qualcosa come Salesforce Data Cloud o SAP Business Cloud per ottenere l'accesso zero-copy spesso costa più che fare semplicemente l'ETL di quei dati in Snowflake nel modo tradizionale. Il parere di Jeff: non è tanto una mossa per risparmiare quanto una mossa di semplificazione, e va valutata in quei termini invece di presumere che faccia risparmiare per default.

Cowork si è inoltre arricchito di connettori verso Redshift, Postgres e altri servizi esterni, che funzionano in modo molto simile ai server MCP. Snowflake lo ha dimostrato dal vivo: nella stessa conversazione un agente ha estratto dati da Snowflake e dati di arricchimento da Redshift per rispondere a un'unica domanda.

Coco (in precedenza Cortex Code) ora compare in tutto Snowsight, nel catalogo Horizon e dentro i Workspaces, rappresentato da un'icona a forma di scintilla blu. Alcuni ambiti specifici da conoscere:

• Coco for Desktop è un fork completo di VS Code con una modalità agente (interfaccia in stile chat) e una modalità editor che assomiglia a VS Code standard. Jeff lo sta testando e dice che è davvero ben costruito, anche se come setup principale continua a usare soprattutto VS Code con il plugin Claude Code. Stima di essersi spostato per circa il 15% sull'ecosistema Coco, per i casi in cui gestisce chiaramente meglio i task specifici di Snowflake.
• L'estensione core di Snowflake per VS Code ora include l'accesso diretto a Cortex Code, tramite un'icona a forma di scintilla nell'angolo in alto.
• Esiste un catalogo pubblico di skill al di fuori dell'interfaccia di Coco stessa, e Coco ha anche un plugin per Claude.
• Gli agent cloud ora possono girare in ambienti sandbox isolati dentro Snowsight, così le modifiche guidate dagli agenti non rischiano di distruggere risorse che non dovrebbero toccare.

Cowork non richiede più di scegliere l'agente giusto prima di porre una domanda. Ora un orchestratore capisce quale agente sottostante debba gestire la richiesta, eliminando un passaggio che era parecchio impegnativo per gli utenti non tecnici.

Anche la memoria specifica per utente è una novità, simile al modo in cui Claude mantiene il contesto durante una conversazione. Cowork ora può costruire skill e memoria personali legate a ciò su cui un determinato utente sta lavorando.

L'ecosistema di connettori è più ampio di quanto facesse sembrare la slide: le integrazioni con Slack, Teams e calendario confluiscono ora tutte in Cowork. L'esempio mostrato da Snowflake: si chiede a Cowork "com'è la mia giornata" e lui controlla il calendario, nota una riunione commerciale, recupera le note rilevanti dell'account Salesforce, verifica la cronologia di Slack alla ricerca di menzioni correlate e recupera i dati Snowflake più pertinenti, restituendo poi un vero riepilogo di preparazione per quella riunione.

Le attività pianificate e le automazioni permettono di impostare controlli ricorrenti, come chiedere a Cowork di controllare ogni settimana una specifica pagina di release di prodotto per una funzionalità che si sta aspettando. Jeff lo usa lui stesso per tenere traccia di quando Snowflake rilascerà la possibilità di combinare più artefatti fissati (grafici salvati dalle risposte di Cowork) in una singola dashboard.

Cortex Sense costruisce contesto a partire dalla cronologia delle query, dalle dashboard e dai metadati per migliorare l'accuratezza. Né Ian né Jeff avevano ancora un'idea chiara di come interagirvi direttamente.

La governance intent-driven è forse l'annuncio più interessante di questa sezione. Invece di scrivere manualmente le policy, si descrive un intento in linguaggio naturale, ad esempio assicurarsi che nessun numero di previdenza sociale venga esposto, e Snowflake scansiona l'account alla ricerca di violazioni e aiuta a correggerle.

Le quote AI per utente permettono di limitare la spesa per persona al giorno invece di affidarsi a un unico budget a livello di account. L'approccio pratico di Jeff con i clienti: configurare Claude Sonnet 4.6 come di fatto l'unico modello abilitato in alcuni account, dato che è efficiente e ha un buon prezzo ora che esistono modelli più recenti come Opus e Fable. In questo modo nessuno interroga per sbaglio un modello molto più costoso facendo lievitare i costi in modo imprevisto.

Se il controllo della spesa AI su Snowflake è un tema su cui state lavorando attivamente, The Unofficial AI Cost Optimization Manual for Snowflake approfondisce quote, selezione dei modelli e da dove arrivano davvero i costi.

La replica degli account di nuova generazione usa change data capture basata sui log per il failover cross-region, ora con backup 20 volte più veloci e SLA migliori. Snowflake ha condiviso un dato reale dal palco: durante una grave interruzione cloud dell'anno scorso, 300 clienti hanno effettuato il failover automatico verso una region di backup senza alcun intervento manuale.

Observe by Snowflake è un prodotto di monitoring in stile Datadog, ma è ancora agli inizi. Deriva dall'acquisizione di Observe da parte di Snowflake, e né Ian né Jeff hanno ancora visto una demo funzionante o degli screenshot. Considerando quanto tempo hanno richiesto alcune parti della precedente acquisizione di Select Star per concretizzarsi del tutto, non aspettatevi che Observe arrivi più in fretta.

Natoma sembra essere un modo per collegare in sicurezza Cowork al resto dell'ecosistema aziendale (Slack, Salesforce e strumenti simili) attraverso il provider SSO esistente, che sia Okta o Microsoft. Un dato condiviso da Snowflake: in media oltre 225 casi di utilizzo non autorizzato di "shadow AI" rilevati per organizzazione, ovvero dipendenti che usano strumenti come ChatGPT o assistenti di coding non approvati senza autorizzazione formale. La lettura di Jeff è che Natoma sia probabilmente il meccanismo con cui Snowflake collegherà Cowork in sicurezza allo stack aziendale più ampio, anche se i materiali pubblici non lo esplicitano ancora.

Le dynamic table hanno ricevuto una funzionalità di "frozen period" poco dopo il Summit, che permette di indicare a una dynamic table di non tentare mai di aggiornare dati precedenti a un timestamp specifico, incluse espressioni relative come "oggi meno 30 giorni". Utile se certi record storici devono restare intatti indipendentemente dalle modifiche a monte.

In quasi tutto questo recap emergono due pattern. Primo: Snowflake continua a investire per rendere più economico e semplice far entrare e uscire i dati senza dipendere da vendor esterni: OpenFlow, DataStream, il mirroring di Postgres e le integrazioni zero-copy puntano tutti nella stessa direzione. Secondo: quasi tutto ora passa per Coco o Cowork, ed è chiaramente la direzione in cui si sta muovendo la piattaforma nel suo complesso.

Se gestite i costi su qualcosa al di fuori di Snowflake, SELECT ora supporta Databricks oltre a Snowflake, e il supporto per BigQuery arriverà nel corso di questo trimestre.

Se il controllo dei costi AI su Snowflake è tra le vostre priorità, soprattutto ora che quote per utente e selezione dei modelli fanno parte del quadro, scaricate The Unofficial AI Cost Optimization Manual for Snowflake. L'ha realizzato Jeff, e va ben oltre quello che abbiamo potuto coprire qui.