Snowflake Summit 2026: o que realmente foi lançado e o que isso significa

A Snowflake abriu o evento com duas mudanças de nome que acabam tocando quase todos os outros anúncios. O Cortex Code agora se chama Coco. O Snowflake Intelligence agora se chama Cowork. O Coco foi feito para desenvolvedores e builders. O Cowork foi feito para usuários de negócio que querem respostas, não código.

Quase todas as outras funcionalidades deste resumo rodam no Coco ou alimentam o Cowork. Esse é o fio condutor de todo o evento.

O OpenFlow agora é headless. O OpenFlow extrai e carrega dados no Snowflake, competindo diretamente com ferramentas como o Fivetran e orquestradores como o Dagster. Jeff destacou que a interface do OpenFlow historicamente era difícil de usar. A solução que a Snowflake lançou é um modelo de objetos headless e programável que você controla inteiramente pelo Coco: em vez de ficar clicando em uma interface confusa, você descreve o que quer e um agente constrói.

O Snowflake DataStream é o Kafka dentro do Snowflake. Ele é compatível com o protocolo do Kafka, então, em teoria, basta apontar seus producers Kafka existentes para uma nova URL da Snowflake e os dados começam a chegar direto nas suas tabelas, sem precisar de um bucket intermediário. Ian classificou esse como um dos maiores anúncios do evento: ele elimina toda uma categoria de dependência de fornecedores externos para ingestão em tempo real, e funciona tanto com tabelas nativas do Snowflake quanto com tabelas Iceberg.

O espelhamento de dados do Postgres pode ser o maior anúncio para quem constrói aplicações. Ative uma opção e seus dados do Postgres aparecem automaticamente no Snowflake via change data capture, sem precisar de pipeline de ETL. O BI tradicional é defasado por definição: cargas em batch rodam uma vez por hora ou por dia, então qualquer coisa que aconteceu no sistema de origem desde a última carga ainda não aparece. Isso fecha essa lacuna para casos de uso em que o Postgres é o banco de dados operacional. Ian vê isso como a resposta da Snowflake ao padrão híbrido transacional-analítico para o qual o Unistore foi originalmente criado, sem a complexidade de montar essa arquitetura por conta própria.

O Snowflake Postgres chegou à GA, junto com suporte a private link para contas business-critical, chaves gerenciadas pelo cliente e algo chamado PGLake: uma forma de usar o próprio Postgres como seu catálogo Iceberg em vez de um baseado em JSON. Jeff interpreta isso como uma resposta direta ao DuckLake, que fez primeiro um movimento parecido de catálogo alternativo.

As migrações com IA prometem uma redução de 88% no tempo. Nem Ian nem Jeff estão dispostos a garantir esse número. A leitura de Ian: "Isso é marketing no seu auge, um número tirado do nada para fazer tudo parecer ótimo." Encare como um sinal direcional de que a migração assistida por IA é mais rápida, não como um número para planejar orçamento.

Alguns anúncios aqui se complementam em vez de ficarem isolados:

• Adaptive compute está chegando à GA. É o movimento da Snowflake em direção a algo mais próximo do modelo do BigQuery, em que você pensa menos no dimensionamento de warehouses. A visão de Jeff, baseada no webinar da própria SELECT sobre o tema antes do Summit: ainda há dimensionamento a considerar, mas essa é claramente a direção da Snowflake, e tende a se tornar a opção padrão de compute em alguns anos. Ian apontou uma ressalva importante: vários clientes presumiram que o adaptive compute é um recurso de economia de custos. Não é. Ele foi projetado para melhorar a performance sem ajustes manuais, não para reduzir sua conta.
• Interactive workloads se apoia nas interactive tables e nos interactive warehouses, que existem para competir com o ClickHouse em analytics de baixa latência. Esta versão adiciona dimensionamento de cluster, seleção de chaves e melhorias de precaching.
• O interactive compiler promete um ganho de 40x no tempo de compilação. Jeff investigou e ainda não tem total certeza se isso vale apenas para workloads interativos ou para todas as queries rodando em warehouses padrão do Snowflake. As informações públicas são inconsistentes o suficiente para preferirmos sinalizar a incerteza em vez de chutar.
• A otimização do engine do Unistore foi lançada junto com esses anúncios, com menos detalhes públicos até agora.

O resumo de Ian: interactive workloads e Unistore miram diretamente times que constroem experiências rápidas, no estilo de aplicação, em cima do Snowflake. O adaptive compute foca em workloads mais tradicionais de ETL e BI, e o foco é performance, não custo.

O AI Complete agora lê áudio e vídeo, não apenas texto e imagens.

O Cortex AI Function Studio (preview público) permite criar suas próprias funções Cortex personalizadas. Aponte-o para linhas contendo imagens, peça para sinalizar quais mostram um atributo específico, e ele retorna uma função que você pode chamar como qualquer outra. Times de plataforma podem validar a função antes de liberá-la amplamente.

A xAI entra na lista de modelos, ao lado de Anthropic, OpenAI, Google, Meta, Mistral e DeepSeek. Isso importa menos pelo Grok em si e mais pelo que sinaliza: a Snowflake está se posicionando como uma camada segura de agregação para qualquer LLM que você queira usar, governada pelas suas credenciais existentes do Snowflake em vez de gerenciar chaves de API separadas por provedor.

O agentic search é fácil de confundir com o Cortex Search existente. A diferença: o Cortex Search retorna trechos de texto e respostas verbosas a partir de documentos não estruturados. O agentic search foi feito para retornar uma única resposta determinística, então uma pergunta como "quantos contratos estão datados de 2025" volta com um número em vez de uma pilha de trechos de contrato.

Os code bundles permitem rodar Python como um arquivo .py simples. Antes, rodar Python no Snowflake significava encapsulá-lo em uma stored procedure SQL ou trabalhar em um notebook, e nenhum dos dois suportava fluxos normais de debugging. Agora você sobe um arquivo Python para um stage e o agenda diretamente. Ian comentou quanto tempo isso levou: "Eu tenho que encapsular em outra linguagem para conseguir defini-lo? Não era isso que eu queria." A exigência de stored procedure era uma parte genuinamente desajeitada da experiência do desenvolvedor, e removê-la é importante para conquistar times que só querem escrever Python.

No lado de ML: o Cortex Training (preview privado) permite fazer fine-tuning de modelos abertos como Qwen e Mistral com seus próprios dados, supostamente fazendo um modelo muito menor superar um muito maior depois de treinado no seu dataset específico. O Snowflake Pipeline Builder adiciona uma interface de arrastar e soltar para construir pipelines de ML, no mesmo espírito de ferramentas como o Alteryx, com o Coco disponível para ajudar a estruturar tudo. As extensões de VS Code e Cursor para ML, além de testes A/B online, também passaram para preview público.

O Streamlit no Snowflake chegou à GA, agora rodando em um runtime de contêiner em vez de warehouses dedicados do Streamlit. Pools de contêineres custam uma fração de um crédito de warehouse completo por hora, então isso deve reduzir de forma significativa o custo de rodar apps Streamlit.

O App Runtime resolve um problema real: a descoberta. Jeff testou isso diretamente, implantando o mesmo app tanto no Snowpark Container Services quanto no App Runtime. A diferença funcional é que apps do App Runtime aparecem em uma aba Apps dentro do Snowsight, então as pessoas da empresa conseguem de fato encontrá-los. Apps construídos diretamente no Container Services exigem que alguém já tenha a URL salva nos favoritos, senão ninguém os encontra.

O Snap and Ask permite selecionar um gráfico gerado pelo Cowork e fazer perguntas de acompanhamento diretamente sobre ele. A Snowflake não fez demonstração ao vivo, então por enquanto não há muito mais a dizer além de ficar de olho nos próximos lançamentos.

O Iceberg v3 chegou à GA, e a Snowflake afirma ter o suporte a v3 mais amplo entre todos os fornecedores Iceberg, incluindo suporte completo a inserts, updates, deletes e merges atômicos. O catálogo REST do Iceberg também viabiliza fluxos entre engines: transforme dados no DuckDB e as mudanças aparecem no Snowflake pelo catálogo compartilhado.

O armazenamento Iceberg gerenciado pela Snowflake está em GA na AWS, com Azure e GCP chegando em breve. Uma mudança estrutural que vale conhecer, mesmo não tendo sido um slide de destaque: a opção de montar e gerenciar seu próprio catálogo Polaris está sendo eliminada por completo. Agora tudo passa pelo catálogo Horizon por padrão, rodando o Polaris por baixo sem nunca expor esse conceito ao usuário. Crie uma tabela do tipo Iceberg e ela aparece automaticamente no Horizon.

A leitura de Ian sobre a adoção do Iceberg de forma mais ampla, com base na base de clientes da SELECT: ela ainda está concentrada em dois grupos. Empresas digital-native com datasets muito grandes e times de engenharia fortes (pense em Coinbase e Shopify) e grandes corporações com o quadro de engenheiros necessário para administrar a complexidade. O investimento contínuo da Snowflake aqui busca reduzir essa barreira de entrada.

Durante o webinar, Paul Horan perguntou se o RBAC granular (filtro de linhas, mascaramento de colunas) se estende ao próprio catálogo REST do Iceberg, de modo que consumidores usando algo como o Athena sejam governados da mesma forma que usuários do Snowflake. Nem Ian nem Jeff tinham uma resposta segura. A experiência de Jeff tem sido manter a governança dentro da camada do Snowflake e usar a API REST apenas para movimentação de dados, o que contorna a questão em vez de respondê-la. Isso parece um problema em aberto de verdade para quem tenta construir uma arquitetura genuinamente multi-engine sem duplicar uma camada de governança em cada engine.

Outras atualizações de compartilhamento de dados:

• O recompartilhamento de dados agora inclui uma flag que permite aos provedores decidir se seus consumidores podem recompartilhar os dados adiante.
• O open sharing permite expor dados a clientes que não usam Snowflake por meio de uma API REST, sem exigir conta Snowflake ou reader account do lado deles.
• As clean rooms também receberam atualizações, embora isso esteja fora do que Ian ou Jeff se sentiram seguros para detalhar.
• O ecossistema zero-copy se expandiu para incluir SAP, Workday e IBM watsonx.data (escrito assim mesmo, não é erro de digitação), juntando-se à integração existente com o Salesforce.

Nesse último ponto, tanto Ian quanto Jeff questionaram um pouco o enquadramento. Montar algo como o Salesforce Data Cloud ou o SAP Business Cloud para ter acesso zero-copy muitas vezes custa mais do que simplesmente fazer o ETL desses dados para o Snowflake do jeito tradicional. A visão de Jeff: não é exatamente uma jogada de economia, é uma jogada de simplicidade, e vale avaliar nesses termos em vez de presumir que economiza dinheiro por padrão.

O Cowork também ganhou conectores para Redshift, Postgres e outros serviços externos, funcionando de forma muito parecida com servidores MCP. A Snowflake fez uma demonstração ao vivo: um agente puxou dados do Snowflake e dados de enriquecimento do Redshift na mesma conversa para responder a uma única pergunta.

O Coco (antigo Cortex Code) agora aparece em todo o Snowsight, no catálogo Horizon e dentro dos Workspaces, representado por um ícone de brilho azul. Alguns pontos específicos que vale conhecer:

• O Coco for Desktop é um fork completo do VS Code com um modo agente (interface estilo chat) e um modo editor que se parece com o VS Code padrão. Jeff vem testando e diz que é genuinamente bem construído, embora ainda use principalmente o VS Code com o plugin do Claude Code como configuração principal. Ele estima que está cerca de 15% dentro do ecossistema Coco, nos casos em que ele claramente lida melhor com tarefas específicas do Snowflake.
• A extensão principal do Snowflake para VS Code agora inclui acesso direto ao Cortex Code, por meio de um ícone de brilho no canto superior.
• Existe um catálogo público de skills fora da própria interface do Coco, e o Coco também tem um plugin para o Claude.
• Agentes na nuvem agora podem rodar em ambientes sandbox isolados dentro do Snowsight, para que mudanças feitas por agentes não corram o risco de destruir recursos que não deveriam tocar.

O Cowork não exige mais que você escolha o agente certo antes de fazer uma pergunta. Um orquestrador agora descobre qual agente subjacente deve atender a solicitação, eliminando uma etapa que exigia demais de usuários não técnicos.

A memória por usuário também é novidade, parecida com a forma como o Claude mantém contexto ao longo de uma conversa. O Cowork agora pode acumular skills e memória pessoais ligadas ao que cada usuário anda fazendo.

O ecossistema de conectores é mais amplo do que o slide fez parecer: integrações com Slack, Teams e calendário agora alimentam o Cowork. O exemplo demonstrado pela Snowflake: pergunte ao Cowork "como está o meu dia", e ele checa sua agenda, percebe uma reunião de vendas, puxa as anotações relevantes da conta no Salesforce, verifica o histórico do Slack em busca de menções relacionadas e traz os dados mais relevantes do Snowflake, retornando um resumo de preparação de verdade para aquela reunião.

Tarefas agendadas e automações permitem configurar verificações recorrentes, como pedir ao Cowork para checar semanalmente uma página específica de releases de produto em busca de uma funcionalidade que você está esperando. O próprio Jeff usa isso para acompanhar quando a Snowflake vai lançar a possibilidade de combinar vários artefatos fixados (gráficos salvos das respostas do Cowork) em um único dashboard.

O Cortex Sense constrói contexto a partir do histórico de queries, dashboards e metadados para melhorar a precisão. Nem Ian nem Jeff tinham ainda uma noção clara de como exatamente seria a interação direta com ele.

A governança orientada por intenção talvez seja o anúncio mais interessante desta seção. Em vez de escrever políticas manualmente, você descreve uma intenção em linguagem natural, algo como garantir que nenhum número de Social Security fique exposto, e o Snowflake varre a conta em busca de violações e ajuda você a corrigi-las.

Cotas de IA por usuário permitem limitar o gasto por pessoa por dia em vez de depender de um único orçamento para toda a conta. A abordagem prática de Jeff com clientes: deixar o Claude Sonnet 4.6 como essencialmente o único modelo habilitado em algumas contas, já que ele é eficiente e tem bom preço agora que existem modelos mais novos como Opus e Fable. Assim, ninguém consulta sem querer um modelo muito mais caro e gera uma conta não planejada.

Se controlar o gasto com IA no Snowflake é algo em que você está trabalhando ativamente, o The Unofficial AI Cost Optimization Manual for Snowflake se aprofunda em cotas, seleção de modelos e de onde os custos realmente vêm.

A replicação de contas de nova geração usa change data capture baseado em logs para failover entre regiões, agora com backups 20x mais rápidos e SLAs melhores. A Snowflake compartilhou um dado real no palco: durante uma grande queda na nuvem no ano passado, 300 clientes fizeram failover automaticamente para uma região de backup sem intervenção manual.

O Observe by Snowflake é um produto de monitoramento no estilo Datadog, mas ainda está no início. Ele veio da aquisição da Observe pela Snowflake, e nem Ian nem Jeff viram uma demonstração funcional ou capturas de tela até agora. Considerando quanto tempo algumas partes da aquisição anterior da Select Star levaram para se concretizar totalmente, não espere que o Observe seja lançado mais rápido.

O Natoma parece ser uma forma de conectar o Cowork com segurança ao resto do seu ecossistema de negócios (Slack, Salesforce e ferramentas similares) por meio do seu provedor de SSO existente, seja Okta ou Microsoft. Um dado compartilhado pela Snowflake: mais de 225 instâncias de uso não autorizado de "shadow AI" detectadas por organização, em média, ou seja, funcionários usando ferramentas como o ChatGPT ou assistentes de código não aprovados sem autorização formal. A leitura de Jeff é que o Natoma provavelmente é o mecanismo que a Snowflake usará para plugar o Cowork na stack de negócios mais ampla com segurança, embora os materiais públicos ainda não deixem isso explícito.

As dynamic tables ganharam um recurso de "frozen period" logo após o Summit, permitindo dizer a uma dynamic table para nunca tentar atualizar dados anteriores a um timestamp específico, incluindo expressões relativas como "hoje menos 30 dias". Útil se você precisa que certos registros históricos permaneçam intocados, independentemente de mudanças upstream.

Dois padrões aparecem em quase tudo neste resumo. Primeiro, a Snowflake continua investindo em tornar mais barato e fácil mover dados para dentro e para fora sem depender de fornecedores externos: OpenFlow, DataStream, espelhamento do Postgres e as integrações zero-copy apontam todos na mesma direção. Segundo, quase tudo agora passa pelo Coco ou pelo Cowork, que é claramente para onde a plataforma como um todo está indo.

Se você gerencia custos em algo além do Snowflake, a SELECT agora suporta Databricks além do Snowflake, e o suporte ao BigQuery chega ainda neste trimestre.

Se o controle de custos de IA no Snowflake está no seu radar, especialmente agora que cotas por usuário e seleção de modelos fazem parte do cenário, baixe o The Unofficial AI Cost Optimization Manual for Snowflake. Jeff montou esse material, e ele vai muito além do que conseguimos cobrir aqui.