Snowflake Summit 2026: lo que realmente se lanzó y qué significa

Snowflake arrancó con dos cambios de nombre que terminan tocando casi todos los demás anuncios. Cortex Code ahora se llama Coco. Snowflake Intelligence ahora se llama Cowork. Coco está pensado para desarrolladores y builders. Cowork está pensado para usuarios de negocio que quieren respuestas, no código.

Casi todas las demás funciones de este resumen corren sobre Coco o alimentan a Cowork. Ese es el hilo conductor de todo el evento.

OpenFlow se vuelve headless. OpenFlow extrae y carga datos en Snowflake, compitiendo directamente con herramientas como Fivetran y orquestadores como Dagster. Jeff señaló que la interfaz de OpenFlow siempre ha sido difícil de usar. La solución que lanzó Snowflake es un modelo de objetos headless y programable que se puede manejar por completo desde Coco: en lugar de dar clics en una interfaz confusa, describes lo que quieres y un agente lo construye.

Snowflake DataStream es Kafka sobre Snowflake. Es compatible a nivel de protocolo con Kafka, así que en teoría apuntas tus producers existentes de Kafka a una nueva URL de Snowflake y los datos empiezan a llegar directamente a tus tablas, sin necesidad de un bucket intermedio. Ian lo calificó como uno de los anuncios más grandes del evento: elimina toda una categoría de dependencia de proveedores externos para la ingesta en tiempo real, y funciona tanto con tablas nativas de Snowflake como con tablas Iceberg.

El mirroring de datos de Postgres podría ser el anuncio más importante para quienes construyen aplicaciones. Con solo activar una opción, tus datos de Postgres aparecen automáticamente en Snowflake mediante change data capture, sin necesidad de un pipeline de ETL. El BI tradicional está desactualizado por definición: las cargas batch corren una vez por hora o una vez al día, así que todo lo que ocurrió en tu sistema de origen desde la última carga todavía no aparece. Esto cierra esa brecha en los casos donde Postgres es la base de datos operacional. Ian lo ve como la respuesta de Snowflake al patrón híbrido transaccional-analítico para el que originalmente se creó Unistore, sin la complejidad de montar esa arquitectura por tu cuenta.

Snowflake Postgres llegó a disponibilidad general (GA), junto con soporte de private link para cuentas business-critical, claves gestionadas por el cliente y algo llamado PGLake: una forma de usar el propio Postgres como tu catálogo de Iceberg en lugar de uno basado en JSON. Jeff lo interpreta como una respuesta directa a DuckLake, que hizo primero una jugada similar de catálogo alternativo.

Las migraciones con IA prometen una reducción del 88% en el tiempo. Ni Ian ni Jeff están dispuestos a avalar esa cifra. La lectura de Ian: "Esto es marketing en estado puro, un número sacado de la nada para que se vea muy bien". Tómalo como una señal direccional de que la migración asistida por IA es más rápida, no como un número sobre el cual planificar un presupuesto.

Varios de estos anuncios se complementan entre sí en lugar de funcionar de forma aislada:

• Adaptive compute pasa a GA. Es el movimiento de Snowflake hacia algo más parecido al modelo de BigQuery, donde piensas menos en el tamaño de los warehouses. La opinión de Jeff, basada en el webinar que SELECT dedicó al tema antes del Summit: todavía hay que pensar en el dimensionamiento, pero esta es claramente la dirección hacia la que va Snowflake, y es probable que se convierta en la opción de cómputo predeterminada en unos pocos años. Ian hizo una salvedad importante: varios clientes han asumido que adaptive compute es una función para ahorrar costos. No lo es. Está diseñada para mejorar el rendimiento sin ajustes manuales, no para reducir tu factura.
• Interactive workloads se construye sobre las interactive tables y los interactive warehouses, que existen para competir con ClickHouse en analítica de baja latencia. Esta versión suma además mejoras de dimensionamiento de clústeres, selección de claves y precaching.
• El compilador interactivo promete una aceleración de 40x en el tiempo de compilación. Jeff investigó este punto y todavía no tiene del todo claro si aplica solo a los interactive workloads o a todas las consultas que corren en warehouses estándar de Snowflake. La información pública es lo suficientemente inconsistente como para señalar la incertidumbre en lugar de adivinar.
• La optimización del motor de Unistore se lanzó junto con lo anterior, con menos detalles públicos por ahora.

El resumen de Ian: los interactive workloads y Unistore apuntan directamente a los equipos que construyen experiencias rápidas, estilo aplicación, sobre Snowflake. Adaptive compute se enfoca en workloads más tradicionales de ETL y BI, y se trata de rendimiento, no de costos.

AI Complete ahora procesa audio y video, no solo texto e imágenes.

Cortex AI Function Studio (en vista previa pública) te permite crear tus propias funciones personalizadas de Cortex. Apúntalo a filas que contengan imágenes, pídele que marque cuáles muestran un atributo específico, y te devuelve una función que puedes llamar como cualquier otra. Los equipos de plataforma pueden validar la función antes de desplegarla de forma amplia.

xAI se suma a la lista de modelos, junto a Anthropic, OpenAI, Google, Meta, Mistral y DeepSeek. Esto importa menos por Grok en sí y más por lo que señala: Snowflake se está posicionando como una capa de agregación segura para el LLM que quieras usar, gobernada a través de tus credenciales existentes de Snowflake en lugar de gestionar claves de API separadas por proveedor.

Agentic search es fácil de confundir con el Cortex Search existente. La diferencia: Cortex Search devuelve fragmentos de texto y respuestas extensas a partir de documentos no estructurados. Agentic search está diseñado para devolver una única respuesta determinista, de modo que una pregunta como "cuántos contratos tienen fecha de 2025" se responde con un número en lugar de una pila de extractos de contratos.

Los code bundles te permiten ejecutar Python como un archivo .py común y corriente. Antes, ejecutar Python en Snowflake implicaba envolverlo en un stored procedure de SQL o trabajar en un notebook, y ninguna de las dos opciones soportaba flujos de depuración normales. Ahora subes un archivo de Python a un stage y lo programas directamente. Ian destacó lo mucho que tardó esto en llegar: "¿Tengo que envolverlo en este otro lenguaje para poder definirlo? Eso no es lo que quería". El requisito del stored procedure era una parte genuinamente torpe de la experiencia de desarrollo, y eliminarlo importa para ganarse a los equipos que simplemente quieren escribir Python.

En el lado de ML: Cortex Training (en vista previa privada) te permite hacer fine-tuning de modelos abiertos como Qwen y Mistral con tus propios datos; según se reporta, un modelo mucho más pequeño puede superar a uno mucho más grande una vez entrenado con tu dataset específico. El Snowflake Pipeline Builder suma una interfaz de arrastrar y soltar para construir pipelines de ML, similar en espíritu a herramientas como Alteryx, con Coco disponible para ayudar a armar la estructura. Las extensiones de VS Code y Cursor para ML, además de las pruebas A/B en línea, también pasaron a vista previa pública.

Streamlit en Snowflake llegó a GA, y ahora corre sobre un runtime de contenedores en lugar de warehouses dedicados de Streamlit. Los pools de contenedores se facturan a una fracción del crédito por hora de un warehouse completo, así que esto debería reducir de forma significativa el costo de ejecutar apps de Streamlit.

App Runtime resuelve un problema real: la visibilidad. Jeff lo probó directamente desplegando la misma app tanto en Snowpark Container Services como en App Runtime. La diferencia funcional es que las apps de App Runtime aparecen en una pestaña Apps dentro de Snowsight, así que la gente de toda la empresa realmente puede encontrarlas. Las apps construidas directamente en Container Services requieren que alguien ya tenga la URL guardada en favoritos, o nadie las encuentra.

Snap and Ask te permite seleccionar un gráfico generado por Cowork y hacerle preguntas de seguimiento directamente. Snowflake no lo mostró en vivo, así que por ahora no hay mucho más que decir, salvo estar atentos a los próximos lanzamientos.

Iceberg v3 llegó a GA, y Snowflake afirma tener el soporte de v3 más amplio de todos los proveedores de Iceberg, incluido soporte completo para inserts, updates, deletes y merges atómicos. El catálogo REST de Iceberg también hace posibles los flujos entre motores: transformas datos en DuckDB y los cambios aparecen en Snowflake a través del catálogo compartido.

El almacenamiento de Iceberg gestionado por Snowflake ya está en GA en AWS, y pronto llegará a Azure y GCP. Un cambio estructural que vale la pena conocer aunque no fue una diapositiva destacada: montar y gestionar tu propio catálogo de Polaris desaparece por completo. Ahora todo pasa por el catálogo Horizon de forma predeterminada, que ejecuta Polaris por debajo sin exponer nunca ese concepto al usuario. Creas una tabla de tipo Iceberg y aparece automáticamente en Horizon.

La lectura de Ian sobre la adopción de Iceberg en general, basada en la base de clientes de SELECT: sigue concentrada en dos grupos. Empresas nativas digitales con datasets muy grandes y equipos de ingeniería sólidos (piensa en Coinbase o Shopify), y grandes corporaciones con el personal de ingeniería necesario para gestionar la complejidad. La inversión continua de Snowflake en este frente apunta a bajar esa barrera de entrada.

Durante el webinar, Paul Horan preguntó si el RBAC granular (filtrado de filas, enmascaramiento de columnas) se extiende al propio catálogo REST de Iceberg, de modo que los consumidores que usan algo como Athena queden gobernados igual que los usuarios de Snowflake. Ni Ian ni Jeff tenían una respuesta segura. La experiencia de Jeff ha sido mantener la gobernanza dentro de la capa de Snowflake y usar la API REST únicamente para mover datos, lo cual esquiva la pregunta en lugar de responderla. Esto parece un problema abierto real para cualquiera que intente construir una arquitectura genuinamente multi-motor sin duplicar una capa de gobernanza en cada motor.

Otras novedades en el intercambio de datos:

• El resharing de datos ahora incluye un flag que permite a los proveedores decidir si sus consumidores pueden, a su vez, volver a compartir los datos con terceros.
• Open sharing te permite exponer datos a clientes que no usan Snowflake a través de una API REST, sin que necesiten una cuenta de Snowflake ni una reader account.
• Los clean rooms también recibieron actualizaciones, aunque esto queda fuera de lo que Ian o Jeff se sentían con la confianza de comentar en detalle.
• El ecosistema de zero-copy se amplió para incluir SAP, Workday e IBM watsonx.data (escrito así, no es un error), sumándose a la integración existente con Salesforce.

Sobre este último punto, tanto Ian como Jeff cuestionaron un poco el planteamiento. Montar algo como Salesforce Data Cloud o SAP Business Cloud para obtener acceso zero-copy suele costar más que simplemente llevar esos datos a Snowflake con un ETL tradicional. La lectura de Jeff: no es realmente una jugada para ahorrar costos, es una jugada de simplicidad, y conviene evaluarla en esos términos en lugar de asumir que ahorra dinero por defecto.

Cowork también sumó conectores a Redshift, Postgres y otros servicios externos, que funcionan de manera muy similar a los servidores MCP. Snowflake lo demostró en vivo: un agente extrajo datos de Snowflake y datos de enriquecimiento de Redshift en la misma conversación para responder una sola pregunta.

Coco (antes Cortex Code) ahora aparece por todo Snowsight, en el catálogo Horizon y dentro de Workspaces, representado por un ícono azul de destello. Algunos lugares específicos que vale la pena conocer:

• Coco for Desktop es un fork completo de VS Code con un modo agente (interfaz tipo chat) y un modo editor que luce como el VS Code estándar. Jeff lo ha estado probando y dice que está genuinamente bien construido, aunque sigue usando principalmente VS Code con el plugin de Claude Code como su configuración habitual. Calcula que usa el ecosistema de Coco en un 15%, para los casos en que claramente maneja mejor las tareas específicas de Snowflake.
• La extensión principal de Snowflake para VS Code ahora incluye acceso directo a Cortex Code mediante un ícono de destello en la esquina superior.
• Existe un catálogo público de skills fuera de la propia interfaz de Coco, y Coco también tiene un plugin para Claude.
• Los agentes en la nube ahora pueden ejecutarse en entornos sandbox aislados dentro de Snowsight, de modo que los cambios hechos por agentes no corran el riesgo de destruir recursos que no deberían tocar.

Cowork ya no requiere elegir el agente correcto antes de hacer una pregunta. Ahora un orquestador determina qué agente subyacente debe atender la solicitud, eliminando un paso que les exigía demasiado a los usuarios no técnicos.

La memoria por usuario también es nueva, similar a cómo Claude retiene contexto a lo largo de una conversación. Cowork ahora puede desarrollar skills y memoria personales ligadas a aquello en lo que un usuario específico ha estado trabajando.

El ecosistema de conectores es más amplio de lo que mostraba la diapositiva: las integraciones con Slack, Teams y calendario ahora alimentan a Cowork. El ejemplo que mostró Snowflake: le preguntas a Cowork "cómo se ve mi día", y revisa tu calendario, detecta una reunión de ventas, extrae las notas relevantes de la cuenta en Salesforce, busca menciones relacionadas en el historial de Slack y trae los datos más relevantes de Snowflake, para luego devolver un verdadero resumen de preparación para esa reunión.

Las tareas programadas y automatizaciones te permiten configurar revisiones recurrentes, como pedirle a Cowork que revise semanalmente la página de lanzamientos de un producto en busca de una función que estás esperando. El propio Jeff lo está usando para seguir de cerca cuándo Snowflake habilite la posibilidad de combinar varios artefactos fijados (gráficos guardados de las respuestas de Cowork) en un solo dashboard.

Cortex Sense construye contexto a partir del historial de consultas, los dashboards y los metadatos para mejorar la precisión. Ni Ian ni Jeff tenían todavía una idea clara de cómo se interactuaría con él directamente.

La gobernanza basada en intención podría ser el anuncio más interesante de esta sección. En lugar de escribir políticas manualmente, describes una intención en lenguaje natural, algo como asegurarte de que no se exponga ningún número de seguro social, y Snowflake escanea la cuenta en busca de infracciones y te ayuda a corregirlas.

Las cuotas de IA por usuario te permiten limitar el gasto por persona y por día en lugar de depender de un único presupuesto para toda la cuenta. El enfoque práctico de Jeff con sus clientes: dejar Claude Sonnet 4.6 como prácticamente el único modelo habilitado en algunas cuentas, ya que es eficiente y tiene buen precio ahora que existen modelos más nuevos como Opus y Fable. Así nadie consulta por accidente un modelo mucho más caro y genera una factura no planificada.

Si controlar el gasto de IA en Snowflake es algo en lo que estás trabajando activamente, The Unofficial AI Cost Optimization Manual for Snowflake profundiza en cuotas, selección de modelos y de dónde vienen realmente los costos.

La replicación de cuentas de nueva generación usa change data capture basado en logs para el failover entre regiones, ahora con backups 20 veces más rápidos y mejores SLA. Snowflake compartió un dato real desde el escenario: durante una caída importante de la nube el año pasado, 300 clientes hicieron failover automáticamente a una región de respaldo sin intervención manual.

Observe by Snowflake es un producto de monitoreo al estilo Datadog, pero todavía está en una etapa temprana. Surgió de la adquisición de Observe por parte de Snowflake, y ni Ian ni Jeff han visto aún una demo funcional o capturas de pantalla. Considerando lo que han tardado en aterrizar por completo algunas piezas de la adquisición anterior de Select Star, no esperes que Observe llegue más rápido.

Natoma parece ser una forma de conectar Cowork de manera segura con el resto de tu ecosistema de negocio (Slack, Salesforce y herramientas similares) a través de tu proveedor de SSO existente, ya sea Okta o Microsoft. Un dato que compartió Snowflake: se detectan en promedio más de 225 instancias de uso no autorizado de "shadow AI" por organización, es decir, empleados usando herramientas como ChatGPT o asistentes de código no aprobados sin autorización formal. La lectura de Jeff es que Natoma probablemente sea el mecanismo que Snowflake use para conectar Cowork de forma segura con el resto del stack de negocio, aunque los materiales públicos todavía no lo explican de forma explícita.

Las dynamic tables sumaron una función de "frozen period" poco después del Summit, que te permite indicarle a una dynamic table que nunca intente refrescar datos anteriores a una marca de tiempo específica, incluidas expresiones relativas como "hoy menos 30 días". Es útil si necesitas que ciertos registros históricos permanezcan intactos sin importar los cambios en el origen.

Dos patrones se repiten en casi todo este resumen. Primero, Snowflake sigue invirtiendo en que ingresar y extraer datos sea más barato y sencillo sin depender de proveedores externos: OpenFlow, DataStream, el mirroring de Postgres y las integraciones zero-copy apuntan en la misma dirección. Segundo, casi todo pasa ahora por Coco o Cowork, que es claramente hacia donde se dirige la plataforma en su conjunto.

Si gestionas costos más allá de Snowflake, SELECT ahora soporta Databricks además de Snowflake, y el soporte para BigQuery llegará más adelante este trimestre.

Si el control de costos de IA en Snowflake está en tu radar, sobre todo ahora que las cuotas por usuario y la selección de modelos son parte del panorama, descarga The Unofficial AI Cost Optimization Manual for Snowflake. Lo preparó Jeff, y va mucho más allá de lo que pudimos cubrir aquí.