O cenário da gestão de custos do Snowflake em 2026 (resumo do webinar)

• A plataforma do Snowflake se expandiu muito além de computação e armazenamento, e cada novo serviço é um novo lugar onde os custos podem se esconder.
• As funções de IA do Cortex, do Snowflake, são poderosas, mas também o jeito mais fácil de queimar milhares de dólares sem querer. Um cliente gastou US$ 60.000 em três dias com uma query que deveria rodar em QA e acabou rodando em produção.
• Visibilidade tem que vir antes da otimização. As equipes continuam descobrindo workloads que custam centenas de milhares de dólares por ano e que ninguém sabia que existiam.
• As correções com maior ROI costumam ser simples: rodar jobs com menos frequência e fazer right-sizing dos warehouses, não reescrever queries.
• Escalar a gestão de custos em uma organização em crescimento significa dar visibilidade às próprias equipes, e não encaminhar toda pergunta sobre custo para um único time central.

Snowflake costumava significar computação e armazenamento. Esse não é mais o quadro completo. Ian e Dave percorreram a lista crescente de serviços que os clientes agora rodam na plataforma: apps nativos, apps em Streamlit, modelos de machine learning implantados em compute pools, um conjunto de recursos de IA em rápida expansão e até workloads de Postgres após a aquisição da Crunchy Data pelo Snowflake.

Cada um deles aparece como uma nova linha na fatura. Isso cria um problema real de monitoramento: se a sua ferramenta de acompanhamento não sabe que um novo serviço existe, você simplesmente não vai ver quanto ele custa. O SELECT mantém um time de quase 30 engenheiros cujo trabalho é exclusivamente acompanhar os lançamentos do Snowflake, para que novas fontes de custo sejam suportadas assim que entram no ar, e não meses depois.

Dave acrescentou que isso não é só um incômodo técnico. A liderança está cada vez mais tomando decisões sobre onde os workloads devem rodar, e não dá para fazer isso sem transparência real de custos para sustentar a escolha.

As funções do Cortex no Snowflake (agora chamadas de AI SQL) permitem rodar IA diretamente sobre os dados que já estão dentro do Snowflake. O exemplo do Dave: filtrar avaliações de produtos para manter apenas aquelas em que o cliente expressou frustração, em uma única query. Há alguns anos, isso significava pessoas revisando e classificando cada registro manualmente.

Essa conveniência vem com um risco real. Dave compartilhou o caso de um cliente: uma query com uma função do Cortex embutida deveria rodar em QA. Em vez disso, rodou em produção contra o dataset completo e queimou US$ 60.000 em tokens ao longo de três dias, sem nenhum resultado útil para mostrar.

Ian explicou por que isso acontece com tanta facilidade. O uso de IA é cobrado por tokens de entrada e tokens de saída. Os tokens de entrada são razoavelmente previsíveis com antecedência, já que você consegue estimar o tamanho do que está alimentando o modelo. Os tokens de saída não são, porque o quanto o modelo gera depende da pergunta em si. É essa assimetria que torna os custos de IA tão difíceis de prever antes de executar algo.

Como ter visibilidade sobre os gastos com IA no Snowflake?

O schema de account usage do Snowflake inclui várias views para IA. A maioria funciona como as outras views de account usage, mostrando o uso por hora, detalhado por modelo. A view de uso do AI SQL é no nível de query: você consegue ver o modelo usado e o texto da query, mas não o prompt em si. A opção mais granular é a tabela de eventos de observabilidade de IA. Ela é acessada por meio de uma table function em vez de uma view padrão e pode mostrar os prompts que estão gerando o uso. Costuma ser mais lenta de consultar e, pelo que Ian entende, não é persistente, o que dificulta análises de longo prazo.

Os budgets e quotas de IA do Snowflake realmente impedem gastos descontrolados?

Em grande parte, sim, com uma lacuna importante. Os budgets de IA permitem definir um limite mensal de créditos para uma conta ou um grupo de objetos com tags, cobrindo Cortex agents, Cortex search e funções de IA, e avisam quando esse limite é ultrapassado. As quotas por usuário vão além e de fato bloqueiam o uso, embora a aplicação leve alguns minutos para entrar em vigor, em vez de interromper uma query instantaneamente.

A lacuna: uma única requisição grande ainda pode estourar o limite antes de o sistema reagir. O exemplo do Ian foi rodar uma função de análise de sentimento sobre uma tabela gigantesca de avaliações de uma só vez. Você pode gastar US$ 10.000, e só a próxima query é bloqueada. As quotas ainda capturam os casos repetitivos ou que rodam o fim de semana inteiro, e Ian disse que configurá-las é a lição número um a levar da sessão. Mas elas não substituem boas práticas, como testar em QA com datasets limitados antes de tocar em produção.

Como medir o ROI dos gastos com IA?

Não existe fórmula universal. Comece pelo lado que dá para medir com precisão, que é o custo. Para o lado do valor, depende do caso de uso. Se a IA substitui algo que já existia, como uma equipe que classificava sentimento manualmente, compare o custo antigo em tempo e computação com o novo. Se ela viabiliza algo novo, você geralmente trabalha com indicadores indiretos: tempo economizado, velocidade de tickets ou histórias em um sistema como o Jira, ou receita recuperada. Quando nada disso traz uma resposta clara, a sugestão do Ian foi direta: desligue e veja quem reclama.

Antes de qualquer trabalho de otimização, você precisa saber quanto as coisas realmente custam. Ian contou o caso de um cliente que acessou o SELECT pela primeira vez e encontrou, no topo da lista, um workload custando US$ 850.000 por ano, impulsionado em grande parte por uma função de IA rodando dentro do que acabou se revelando um job de QA. Eles desligaram. Nenhuma investigação profunda foi necessária, porque a visibilidade sozinha revelou a correção.

A versão do Dave da mesma lição: um cliente gastando US$ 10.000 por ano só para enviar um e-mail a partir do Snowflake. Bastou olhar o custo real para mover esse workload para um lugar mais barato. Ele também ouve "eu achei que tinha desligado isso há três meses" o tempo todo quando os clientes veem pela primeira vez os custos query a query e workload a workload.

Com a visibilidade em mãos, a próxima pergunta é se uma otimização vale o seu tempo. Gastar um dia de engenharia para economizar US$ 500 em armazenamento é um péssimo negócio. Gastar algumas horas para economizar US$ 20.000 é uma decisão fácil. O conselho do Ian: faça essa conta antes de começar e ataque os ganhos rápidos antes de reescrever qualquer SQL.

Quais são as correções com maior ROI quando você sabe onde procurar?

1. Rode as coisas com menos frequência. Um job que roda de hora em hora e custa US$ 10.000 por ano cai para menos de US$ 500 por ano se só precisar rodar diariamente — uma redução de 96% com uma única mudança de configuração. Até passar de uma vez por hora para a cada três horas economiza cerca de dois terços do custo.
2. Faça right-sizing do seu warehouse. Cada aumento de tamanho dobra a computação e o custo, então um warehouse maior só compensa se o tempo de query realmente cair pela metade também. O exemplo do Ian: reduzir um warehouse de ingestão de Large para Extra Small levou o tempo médio de query de cerca de cinco segundos para cerca de vinte — um atraso que ninguém notou — e economizou US$ 50.000 por ano. Uma heurística útil é cerca de 125 partições escaneadas por núcleo de CPU (um warehouse Large tem 64 núcleos), então uma query que escaneia apenas 500 partições raramente precisa de mais do que um Extra Small.
3. Fique de olho no padrão Snowflake-como-fila-de-mensagens. Dave já viu equipes usarem o Snowflake como uma fila Kafka, rodando milhões de operações minúsculas em vez das operações em lote maiores para as quais ele foi projetado. Isso mantém os warehouses rodando sem parar e sai caro. Use a tecnologia certa para cada workload.
4. Considere escalar horizontalmente, não só verticalmente. Dave apontou que as pessoas costumam escolher o tamanho do warehouse e negligenciar o número de clusters. Aumentar o número de clusters pode entregar resultados melhores do que simplesmente aumentar o tamanho do warehouse, dependendo do workload.
5. Use agentes de código com IA para as reescritas mais difíceis. O exemplo interno do SELECT trazido pelo Ian: um dataset que era totalmente recriado a cada execução custava mais de US$ 8.000 por ano, e algumas horas tornando a query incremental eliminaram esse gasto. Ele acrescentou que agentes de código como o Coco agora tornam esse tipo de reescrita possível em horas, quando antes levava dias.

Sobre ingestão especificamente, Ian disse que ela costuma representar cerca de 10 a 20% do gasto com computação, e essa fatia vem caindo. O Snowpipe Streaming reduziu os custos de ingestão em aproximadamente 10x para alguns clientes, e a adoção do Iceberg também ajuda. As duas economias de ingestão mais fáceis segundo o Dave: traga apenas as tabelas e colunas de que você realmente precisa e ajuste a frequência de atualização à necessidade real do negócio, em vez de buscar por padrão algo o mais próximo possível do tempo real.

As equipes estão movendo workloads para engines mais baratos como o DuckDB, ou adotando Iceberg para economizar?

Em pequena escala, às vezes. Um único engenheiro em uma empresa menor pode razoavelmente direcionar workloads específicos para algo como o DuckDB. Em grande escala, com milhares de usuários que precisam de controles de acesso centralizados, é raro, porque fica difícil demais de gerenciar. Dave disse que nunca tinha realmente pensado no Iceberg como medida de economia. O atrativo dele é a interoperabilidade: você reutiliza os mesmos dados de vários lugares sem gastar mais computação. Ian acrescentou que o Iceberg pode reduzir custos de ingestão e evita pagar duas vezes pelo armazenamento, mas rodar múltiplos engines de computação em cima dele não é algo que ele vê com frequência. Dave disse que o que vê mais são clientes movendo workloads inteiros entre plataformas, como do Snowflake para o Databricks ou do Postgres para o Snowflake e de volta, conforme o melhor encaixe. Para ele, trata-se de conservar computação, e não de otimizar armazenamento.

Um único time central de dados respondendo a toda pergunta sobre custos não escala. Dave, que já foi essa pessoa, descreveu como um time pequeno vira gargalo quando todas as solicitações de dados passam por ele. A solução é dar aos usuários finais visibilidade sobre os custos que eles geram, para que cada um aja com responsabilidade em relação ao que gasta dentro da empresa.

Isso começa com a alocação de custos: mapear os gastos para as equipes responsáveis por eles, de modo que a atenção das pessoas fique no que elas podem controlar. Públicos diferentes também precisam de visões diferentes. Executivos geralmente querem dashboards de alto nível com custos por grupo ao longo de um dia, semana ou mês. Quem está na prática quer ver os itens específicos que a própria equipe está rodando.

Tornar essa informação fácil de acessar importa tanto quanto tê-la. Dave sugeriu construir dashboards relevantes para cada público, ou dar às pessoas acesso a um servidor MCP para que possam fazer as perguntas certas ao Claude. Ian acrescentou que, às vezes, os usuários só precisam de informação curada em uma interface fácil de usar: me entregue pronto, não me faça sair pescando.

Um centro de excelência tem um papel real, mas restrito. O time central deve orientar os usuários sobre como melhorar seus custos e disseminar esse conhecimento pela organização, e não assumir a responsabilidade de fazer cada otimização sozinho. Como colocou o Ian, fazer essas coisas individualmente em nome da organização inteira só leva você até certo ponto.