Snowflake Summit 2026: Was wirklich ausgeliefert wurde – und was das für Sie heißt

Snowflake startete mit zwei Umbenennungen, die am Ende fast jede weitere Ankündigung berühren. Cortex Code heißt jetzt Coco. Snowflake Intelligence heißt jetzt Cowork. Coco richtet sich an Entwickler und Builder. Cowork richtet sich an Business-Anwender, die Antworten wollen – keinen Code.

Fast jedes andere Feature in diesem Rückblick läuft entweder auf Coco oder fließt in Cowork ein. Das ist der rote Faden der gesamten Veranstaltung.

OpenFlow wird headless. OpenFlow extrahiert und lädt Daten nach Snowflake und konkurriert damit direkt mit Tools wie Fivetran und Orchestratoren wie Dagster. Jeff merkte an, dass die OpenFlow-Oberfläche in der Vergangenheit schwer zu bedienen war. Snowflakes Lösung ist ein headless, programmierbares Objektmodell, das sich vollständig über Coco steuern lässt: Statt sich durch eine verwirrende Oberfläche zu klicken, beschreiben Sie, was Sie wollen, und ein Agent baut es.

Snowflake DataStream ist Kafka auf Snowflake. Es ist wire-kompatibel mit Kafka – theoretisch richten Sie Ihre bestehenden Kafka-Producer also einfach auf eine neue Snowflake-URL, und die Daten landen direkt in Ihren Tabellen, ganz ohne Zwischen-Bucket. Für Ian war das eine der größeren Ankündigungen der Veranstaltung: Sie beseitigt eine ganze Kategorie externer Anbieterabhängigkeiten für Echtzeit-Ingestion und funktioniert sowohl mit nativen Snowflake-Tabellen als auch mit Iceberg-Tabellen.

Postgres-Daten-Mirroring ist möglicherweise die wichtigste Einzelankündigung für Anwendungsentwickler. Einen Schalter umlegen, und Ihre Postgres-Daten erscheinen per Change Data Capture automatisch in Snowflake – keine ETL-Pipeline nötig. Klassisches BI ist per Definition veraltet: Batch-Loads laufen einmal pro Stunde oder einmal am Tag, alles, was seit dem letzten Load im Quellsystem passiert ist, taucht also noch nicht auf. Diese Lücke wird nun für alle Anwendungsfälle geschlossen, in denen Postgres die operative Datenbank ist. Ian sieht darin Snowflakes Antwort auf das hybride transaktional-analytische Muster, für das Unistore ursprünglich gebaut wurde – ohne die Komplexität, diese Architektur selbst aufzusetzen.

Snowflake Postgres ist jetzt GA – zusammen mit Private-Link-Unterstützung für Business-Critical-Accounts, kundenseitig verwalteten Schlüsseln und etwas namens PGLake: einer Möglichkeit, Postgres selbst als Iceberg-Katalog zu nutzen statt eines JSON-basierten. Jeff liest das als direkte Antwort auf DuckLake, das zuerst einen ähnlichen Schritt in Richtung Katalog-Alternative gemacht hat.

KI-gestützte Migrationen sollen 88 % Zeitersparnis bringen. Weder Ian noch Jeff wollen für diese Zahl die Hand ins Feuer legen. Ians Einschätzung: "Das ist Marketing in Reinform – eine Zahl, die aus der Luft gegriffen ist, damit es richtig gut aussieht." Nehmen Sie es als Richtungssignal, dass KI-gestützte Migration schneller ist – nicht als Zahl, auf der man ein Budget aufbaut.

Einige Ankündigungen hier bauen aufeinander auf, statt für sich allein zu stehen:

• Adaptive Compute geht in GA. Es ist Snowflakes Schritt in Richtung eines Modells, das dem von BigQuery näherkommt und bei dem man sich weniger Gedanken über Warehouse-Größen macht. Jeffs Einschätzung, basierend auf SELECTs eigenem Webinar zu diesem Thema vor dem Summit: Sizing bleibt weiterhin ein Thema, aber die Richtung ist eindeutig – und Adaptive Compute dürfte innerhalb weniger Jahre zur Standard-Compute-Option werden. Ian wies auf einen wichtigen Vorbehalt hin: Mehrere Kunden haben angenommen, Adaptive Compute sei ein Kostensenkungs-Feature. Ist es nicht. Es ist darauf ausgelegt, die Performance ohne manuelles Tuning zu verbessern – nicht darauf, Ihre Rechnung zu senken.
• Interactive Workloads baut auf Interactive Tables und Interactive Warehouses auf, die bei latenzarmer Analytik mit ClickHouse konkurrieren sollen. Dieses Release ergänzt Cluster-Sizing, Key-Auswahl und Verbesserungen beim Precaching.
• Der Interactive Compiler verspricht eine 40-fache Beschleunigung der Kompilierzeit. Jeff hat sich eingehender damit beschäftigt und ist sich immer noch nicht ganz sicher, ob das nur für Interactive Workloads gilt oder für jede Query auf Standard-Snowflake-Warehouses. Die öffentlichen Informationen sind so widersprüchlich, dass wir die Unsicherheit lieber benennen, statt zu raten.
• Unistore-Engine-Optimierungen kamen parallel dazu, bislang mit weniger öffentlichen Details.

Ians Fazit: Interactive Workloads und Unistore zielen klar auf Teams, die schnelle, anwendungsähnliche Erlebnisse auf Snowflake aufbauen. Adaptive Compute richtet sich an klassischere ETL- und BI-Workloads – und es geht dabei um Performance, nicht um Kosten.

AI Complete liest jetzt Audio und Video, nicht mehr nur Text und Bilder.

Mit Cortex AI Function Studio (Public Preview) bauen Sie eigene, individuelle Cortex-Funktionen. Richten Sie es auf Zeilen mit Bildern, bitten Sie es, diejenigen mit einem bestimmten Merkmal zu markieren, und Sie erhalten eine Funktion, die sich wie jede andere aufrufen lässt. Plattform-Teams können die Funktion prüfen, bevor sie breit ausgerollt wird.

xAI stößt zur Modellauswahl hinzu, neben Anthropic, OpenAI, Google, Meta, Mistral und DeepSeek. Das ist weniger wegen Grok selbst relevant, sondern wegen des Signals dahinter: Snowflake positioniert sich als sichere Aggregationsschicht für das LLM Ihrer Wahl, gesteuert über Ihre bestehenden Snowflake-Zugangsdaten statt über separate API-Keys pro Anbieter.

Agentic Search lässt sich leicht mit dem bestehenden Cortex Search verwechseln. Der Unterschied: Cortex Search liefert Textausschnitte und wortreiche Antworten aus unstrukturierten Dokumenten. Agentic Search ist darauf ausgelegt, eine einzelne, deterministische Antwort zurückzugeben – auf eine Frage wie "wie viele Verträge sind auf 2025 datiert" kommt also eine Zahl zurück statt eines Stapels von Vertragsauszügen.

Mit Code Bundles führen Sie Python als normale .py-Datei aus. Bisher bedeutete Python in Snowflake, den Code in eine SQL Stored Procedure zu verpacken oder in einem Notebook zu arbeiten – beides ohne Unterstützung für normale Debugging-Workflows. Jetzt laden Sie eine Python-Datei in eine Stage hoch und planen sie direkt ein. Ian merkte an, wie lange das gedauert hat: "Ich muss es in eine andere Sprache verpacken, nur um es zu definieren? Das ist nicht das, was ich wollte." Die Stored-Procedure-Pflicht war ein wirklich sperriger Teil der Developer Experience, und sie zu beseitigen ist wichtig, um Teams zu gewinnen, die einfach nur Python schreiben wollen.

Auf der ML-Seite: Mit Cortex Training (Private Preview) lassen sich offene Modelle wie Qwen und Mistral auf eigenen Daten feinabstimmen – Berichten zufolge übertrifft ein deutlich kleineres Modell nach dem Training auf Ihrem spezifischen Datensatz ein wesentlich größeres. Der Snowflake Pipeline Builder ergänzt eine Drag-and-drop-Oberfläche für den Bau von ML-Pipelines, vom Ansatz her vergleichbar mit Tools wie Alteryx, mit Coco als Hilfe beim Aufsetzen. Außerdem sind VS-Code- und Cursor-Erweiterungen für ML sowie Online-A/B-Testing in die Public Preview gewandert.

Streamlit auf Snowflake ist GA und läuft jetzt auf einer Container-Runtime statt auf dedizierten Streamlit-Warehouses. Container-Pools werden mit einem Bruchteil eines vollen Warehouse-Credits pro Stunde abgerechnet – das sollte die Kosten für den Betrieb von Streamlit-Apps spürbar senken.

App Runtime löst ein reales Problem: Auffindbarkeit. Jeff hat das direkt getestet und dieselbe App sowohl in Snowpark Container Services als auch in App Runtime deployt. Der funktionale Unterschied: App-Runtime-Apps erscheinen in einem Apps-Tab innerhalb von Snowsight, sodass Mitarbeitende im gesamten Unternehmen sie tatsächlich finden können. Apps, die direkt in Container Services gebaut werden, setzen voraus, dass jemand die URL bereits als Lesezeichen hat – sonst findet sie niemand.

Mit Snap and Ask wählen Sie ein von Cowork generiertes Diagramm aus und stellen direkt Anschlussfragen dazu. Snowflake hat es nicht live demonstriert, daher gibt es vorerst nicht mehr zu sagen – behalten Sie es in den kommenden Releases im Auge.

Iceberg v3 hat GA erreicht, und Snowflake beansprucht die breiteste v3-Unterstützung aller Iceberg-Anbieter, einschließlich voller Unterstützung für atomare Inserts, Updates, Deletes und Merges. Der Iceberg REST Catalog ermöglicht zudem engineübergreifende Workflows: Transformieren Sie Daten in DuckDB, und die Änderungen erscheinen über den gemeinsamen Katalog in Snowflake.

Snowflake-managed Iceberg Storage ist GA auf AWS, Azure und GCP folgen in Kürze. Eine strukturelle Änderung, die man kennen sollte, auch wenn sie keine Headline-Folie war: Das Aufsetzen und Verwalten eines eigenen Polaris-Katalogs entfällt komplett. Alles läuft jetzt standardmäßig über den Horizon-Katalog, der Polaris darunter betreibt, ohne dieses Konzept dem Nutzer je zu zeigen. Legen Sie eine Tabelle vom Typ Iceberg an, erscheint sie automatisch in Horizon.

Ians Einschätzung zur Iceberg-Adoption insgesamt, basierend auf SELECTs Kundenbasis: Sie konzentriert sich nach wie vor auf zwei Gruppen. Digital-native Unternehmen mit sehr großen Datensätzen und starken Engineering-Teams (etwa Coinbase oder Shopify) – und Großunternehmen mit genug Engineering-Personal, um die Komplexität zu stemmen. Snowflakes fortgesetzte Investitionen zielen darauf ab, diese Einstiegshürde zu senken.

Während des Webinars kam eine Frage von Paul Horan, ob sich feingranulares RBAC (Zeilenfilterung, Spaltenmaskierung) auf den Iceberg REST Catalog selbst erstreckt, sodass Konsumenten, die etwa Athena nutzen, denselben Governance-Regeln unterliegen wie Snowflake-Nutzer. Weder Ian noch Jeff hatten darauf eine sichere Antwort. Jeffs Erfahrung: Governance innerhalb der Snowflake-Schicht belassen und die REST-API rein für den Datentransport nutzen – was die Frage eher umgeht als beantwortet. Das sieht nach einem echten offenen Problem für alle aus, die eine echte Multi-Engine-Architektur bauen wollen, ohne eine Governance-Schicht über jede Engine hinweg zu duplizieren.

Weitere Data-Sharing-Updates:

• Data Resharing enthält jetzt ein Flag, mit dem Anbieter entscheiden können, ob ihre Konsumenten Daten weiter teilen dürfen.
• Mit Open Sharing stellen Sie Daten über eine REST-API für Nicht-Snowflake-Kunden bereit – ohne dass diese ein Snowflake-Konto oder einen Reader-Account benötigen.
• Auch Clean Rooms erhielten Updates, allerdings liegt das außerhalb dessen, wozu sich Ian oder Jeff im Detail äußern wollten.
• Das Zero-Copy-Ökosystem wurde um SAP, Workday und IBM watsonx.data erweitert (so geschrieben, kein Tippfehler) und ergänzt die bestehende Salesforce-Integration.

Beim letzten Punkt widersprachen sowohl Ian als auch Jeff der Darstellung ein Stück weit. Etwas wie Salesforce Data Cloud oder SAP Business Cloud aufzusetzen, um Zero-Copy-Zugriff zu erhalten, kostet oft mehr, als diese Daten schlicht klassisch per ETL nach Snowflake zu laden. Jeffs Einschätzung: Es geht nicht wirklich um Kosteneinsparung, sondern um Einfachheit – und genau unter diesem Gesichtspunkt sollte man es bewerten, statt standardmäßig anzunehmen, dass es Geld spart.

Cowork hat zudem Konnektoren zu Redshift, Postgres und anderen externen Diensten erhalten, die ähnlich wie MCP-Server funktionieren. Snowflake zeigte das live: Ein Agent zog in derselben Konversation Daten aus Snowflake und Anreicherungsdaten aus Redshift heran, um eine einzige Frage zu beantworten.

Coco (ehemals Cortex Code) taucht jetzt überall in Snowsight, im Horizon-Katalog und in Workspaces auf, erkennbar an einem blauen Sparkle-Icon. Ein paar konkrete Oberflächen, die man kennen sollte:

• Coco for Desktop ist ein vollwertiger VS-Code-Fork mit einem Agent-Modus (Chat-Oberfläche) und einem Editor-Modus, der wie Standard-VS-Code aussieht. Jeff testet es derzeit und sagt, es sei wirklich gut gebaut – auch wenn er primär weiterhin VS Code mit dem Claude-Code-Plugin als Haupt-Setup nutzt. Er schätzt, dass er für die Fälle, in denen es Snowflake-spezifische Aufgaben klar besser erledigt, zu etwa 15 % im Coco-Ökosystem unterwegs ist.
• Die zentrale Snowflake-Erweiterung für VS Code enthält jetzt direkten Cortex-Code-Zugriff über ein Sparkle-Icon in der oberen Ecke.
• Ein öffentlicher Skill-Katalog existiert außerhalb der Coco-Oberfläche selbst, und Coco hat zudem ein Plugin für Claude.
• Cloud-Agenten können jetzt in isolierten Sandbox-Umgebungen innerhalb von Snowsight laufen, sodass agentengetriebene Änderungen keine Ressourcen gefährden, die sie nicht anfassen sollten.

Cowork verlangt nicht mehr, dass man vor einer Frage den richtigen Agenten auswählt. Ein Orchestrator ermittelt jetzt, welcher zugrunde liegende Agent die Anfrage bearbeiten soll – und beseitigt damit einen Schritt, der nicht-technischen Nutzern viel abverlangt hat.

Nutzerspezifisches Gedächtnis ist ebenfalls neu, ähnlich wie Claude Kontext über eine Konversation hinweg behält. Cowork kann jetzt persönliche Skills und Erinnerungen aufbauen, die daran geknüpft sind, woran ein bestimmter Nutzer gearbeitet hat.

Das Konnektor-Ökosystem ist breiter, als es die Folie wirken ließ: Slack-, Teams- und Kalender-Integrationen fließen jetzt allesamt in Cowork ein. Das Beispiel aus Snowflakes Demo: Fragen Sie Cowork "wie sieht mein Tag aus", prüft es Ihren Kalender, bemerkt ein Sales-Meeting, zieht die relevanten Salesforce-Account-Notizen heran, durchsucht die Slack-Historie nach zugehörigen Erwähnungen und holt die relevantesten Snowflake-Daten – und liefert dann ein konkretes Vorbereitungs-Briefing für dieses Meeting.

Geplante Tasks und Automatisierungen ermöglichen wiederkehrende Prüfungen – etwa Cowork wöchentlich eine bestimmte Produkt-Release-Seite nach einem Feature prüfen zu lassen, auf das Sie warten. Jeff nutzt das selbst, um zu verfolgen, wann Snowflake die Möglichkeit ausliefert, mehrere angepinnte Artefakte (aus Cowork-Antworten gespeicherte Diagramme) auf einem einzigen Dashboard zu kombinieren.

Cortex Sense baut Kontext aus Query-Historie, Dashboards und Metadaten auf, um die Genauigkeit zu verbessern. Weder Ian noch Jeff hatten bislang ein klares Bild davon, wie genau man direkt damit interagieren würde.

Intent-driven Governance ist vielleicht die interessanteste Ankündigung in diesem Abschnitt. Statt Richtlinien manuell zu schreiben, beschreiben Sie eine Absicht in natürlicher Sprache – etwa sicherzustellen, dass keine Sozialversicherungsnummern offengelegt werden –, und Snowflake durchsucht den Account nach Verstößen und hilft Ihnen, sie zu beheben.

Mit KI-Quoten pro Nutzer deckeln Sie Ausgaben pro Person und Tag, statt sich auf ein einziges kontoweites Budget zu verlassen. Jeffs praktischer Ansatz bei Kunden: Claude Sonnet 4.6 in manchen Accounts als im Grunde einziges freigeschaltetes Modell aufzusetzen, da es effizient und preislich attraktiv ist, seit neuere Modelle wie Opus und Fable existieren. So fragt niemand versehentlich ein deutlich teureres Modell ab und verursacht eine ungeplante Rechnung.

Wenn die Kontrolle von KI-Ausgaben auf Snowflake ein Thema ist, an dem Sie aktiv arbeiten, geht The Unofficial AI Cost Optimization Manual for Snowflake tiefer auf Quoten, Modellauswahl und die tatsächlichen Kostentreiber ein.

Next-Gen Account Replication nutzt log-basiertes Change Data Capture für regionsübergreifendes Failover, jetzt mit 20-fach schnelleren Backups und besseren SLAs. Snowflake nannte auf der Bühne einen realen Datenpunkt: Während eines großen Cloud-Ausfalls im vergangenen Jahr schwenkten 300 Kunden automatisch und ohne manuelles Eingreifen auf eine Backup-Region um.

Observe by Snowflake ist ein Monitoring-Produkt im Stil von Datadog, steht aber noch ganz am Anfang. Es stammt aus Snowflakes Observe-Akquisition, und weder Ian noch Jeff haben bislang eine funktionierende Demo oder Screenshots gesehen. Angesichts dessen, wie lange einige Teile der früheren Select-Star-Akquisition bis zur vollständigen Umsetzung gebraucht haben, sollte man nicht erwarten, dass Observe schneller ausgeliefert wird.

Natoma scheint ein Weg zu sein, Cowork sicher mit dem Rest Ihres Business-Ökosystems zu verbinden (Slack, Salesforce und ähnliche Tools) – über Ihren bestehenden SSO-Anbieter, egal ob Okta oder Microsoft. Ein Datenpunkt, den Snowflake teilte: Im Schnitt werden pro Organisation über 225 Fälle nicht genehmigter "Schatten-KI"-Nutzung entdeckt – also Mitarbeitende, die Tools wie ChatGPT oder nicht freigegebene Coding-Assistenten ohne formale Genehmigung nutzen. Jeffs Lesart: Natoma ist wahrscheinlich der Mechanismus, mit dem Snowflake Cowork sicher in den breiteren Business-Stack einbindet – auch wenn die öffentlichen Unterlagen das noch nicht explizit so formulieren.

Dynamic Tables haben kurz nach dem Summit ein "Frozen Period"-Feature erhalten, mit dem Sie einer Dynamic Table sagen können, dass sie Daten vor einem bestimmten Zeitstempel niemals aktualisieren soll – einschließlich relativer Ausdrücke wie "heute minus 30 Tage". Nützlich, wenn bestimmte historische Datensätze unabhängig von Upstream-Änderungen unangetastet bleiben müssen.

Zwei Muster ziehen sich durch fast alles in diesem Rückblick. Erstens investiert Snowflake weiter darin, Daten günstiger und einfacher hinein- und wieder herauszubekommen, ohne auf externe Anbieter angewiesen zu sein: OpenFlow, DataStream, Postgres-Mirroring und die Zero-Copy-Integrationen zeigen alle in dieselbe Richtung. Zweitens läuft inzwischen fast alles über Coco oder Cowork – und genau dorthin bewegt sich die Plattform als Ganzes.

Wenn Sie Kosten außerhalb von Snowflake managen: SELECT unterstützt jetzt neben Snowflake auch Databricks, und BigQuery-Unterstützung folgt noch in diesem Quartal.

Wenn KI-Kostenkontrolle auf Snowflake für Sie ein Thema ist – gerade jetzt, wo Quoten pro Nutzer und Modellauswahl Teil des Bildes sind –, laden Sie The Unofficial AI Cost Optimization Manual for Snowflake herunter. Jeff hat es zusammengestellt, und es geht weit über das hinaus, was wir hier abdecken konnten.