Snowflake Gen2 Warehouses: a velocidade vale o custo extra?

Os warehouses Gen2 aproveitam o hardware mais rápido que os provedores de nuvem (AWS, GCP) vêm disponibilizando. Além disso, o time do Snowflake investiu em otimizações de software específicas para os Gen2, que trazem ganhos extras de performance e custo. Praticamente todas as queries devem ter algum ganho vindo das melhorias de hardware, mas workloads específicos colhem benefícios adicionais dessas otimizações de software.

Os Gen2 Warehouses ainda têm disponibilidade limitada, mas devem chegar a mais regiões em breve. Confira aqui se o Gen2 já está disponível na sua região.

Melhorias de hardware

Os virtual warehouses Gen2 do Snowflake rodam sobre a infraestrutura de computação do seu provedor de nuvem, como instâncias EC2 ou máquinas virtuais. Com o tempo, esses provedores atualizam suas instâncias com hardware mais novo. A AWS, por exemplo, lançou recentemente os processadores Graviton4 baseados em ARM. Embora o Snowflake não divulgue exatamente qual hardware usa, é razoável supor que esteja aproveitando o que cada provedor tem de mais recente. Essas melhorias incluem leituras mais rápidas em disco local, CPUs mais potentes e maior throughput de rede — tudo isso contribui para uma performance melhor já de saída.

Melhorias de software

O Snowflake também afirma ter feito uma série de otimizações específicas de software que aceleram workloads de DML (ou seja, jobs que fazem merge/update de dados em tabelas), além de certas queries mais complexas.

Como veremos nos resultados da nossa análise, essas melhorias de software são provavelmente o que está por trás dos maiores ganhos de performance.

Como rodam em hardware mais novo e melhor, os warehouses Gen2 são mais caros. Como mostra a tabela de preços abaixo (fonte), os Gen2 são 35% mais caros na AWS e no GCP, e 25% mais caros no Azure.

Isso traz implicações importantes que todo profissional deve avaliar antes de migrar. Mesmo que as queries fiquem mais rápidas, é preciso garantir que a redução no tempo de computação compense o aumento de custo. Para complicar, a maioria dos profissionais configura os warehouses para suspender após 60 segundos de ociosidade. Ou seja, você vai pagar o preço mais alto também durante esse tempo ocioso — e isso pode entrar na sua conta.

Cálculo do break-even

Como as queries rodam mais rápido no Gen2 e você paga a tarifa mais alta por menos tempo, o cálculo do break-even é:

Redução de tempo necessária (%) = 1 - (1 / Fator de aumento de preço)

No Azure, é preciso reduzir 20% do tempo ativo do warehouse para empatar.

• 1 - (1 / 1,25) = 0,20

Na AWS, é preciso reduzir 25,9% do tempo ativo do warehouse para empatar.

• 1 - (1 / 1,35) = 0,259

Fiz o benchmarking na AWS. Portanto, para manter o custo neutro, precisamos de um ganho de performance de pelo menos 25,9%.

Não esqueça do período mínimo de cobrança de 1 minuto

Lembre-se: toda vez que um warehouse é retomado, você é cobrado por 60 segundos. Então, se uma query sai de 30 segundos no Gen1 para 15 segundos no Gen2, não há economia — pelo contrário, você paga mais. Cabe a você decidir se o ganho de performance vale o custo extra.

O cenário ideal de economia: workloads que rodam por mais de 1 minuto E economizam mais do que o percentual de break-even acima.

A tabela abaixo resume esse conceito.

Criar um novo warehouse Gen2 ou converter um existente para Gen2 é bem simples: basta passar o parâmetro resource_constraint no comando create ou alter. Veja um exemplo de cada:

-- criar novo
CREATE OR REPLACE WAREHOUSE my_wh
WAREHOUSE_SIZE = MEDIUM
RESOURCE_CONSTRAINT = STANDARD_GEN_2;

-- alterar existente
ALTER WAREHOUSE legacy_wh
SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;

O Snowflake já vem com um banco de dados de exemplo contendo o dataset TCP-H, definido pelo Transaction Processing Performance Council para benchmarking de workloads analíticos.

No Snowflake, esses schemas ficam no banco snowflake_sample_data:

• TPCH_SF1
• TPCH_SF10
• TPCH_SF100
• TPCH_SF1000

SF significa Scale Factor (fator de escala). O SF10 é 10x maior que o SF1, e assim por diante. Testamos vários tipos de workloads em SF10, SF100 e SF1000.

Cobrimos três cenários principais no benchmarking:

1. dbt: construção de um projeto dbt composto somente por modelos do tipo Table e testes. A ideia é avaliar se projetos dbt, tão usados no Snowflake, são bons candidatos para os Gen2.
2. Queries de select: aqui simulamos o que aconteceria em uma ferramenta de BI ou em outras aplicações voltadas ao usuário final.
3. Workloads de DML: atualizar/mesclar dados novos no Snowflake é um workload comum nos times de data engineering. Testamos vários cenários (updates, merges, etc.) para entender o impacto.

dbt

Setup

Fizemos um fork e atualizamos um projeto dbt existente que trabalha com os datasets TCPH do Snowflake. Nosso repositório está aqui.

Rodamos o projeto dbt sem restrições em cada dataset, usando warehouses de tamanhos variados, e comparamos Gen1 vs Gen2. Usamos warehouses menores para dados menores e maiores para dados maiores, para simular um cenário realista.

Cada iteração foi construída em um schema novo, para evitar caching e persistir os resultados de cada teste separadamente. Cada build executa 16 modelos de tabela e 43 testes de dados (dbt build --exclude tag:merge-test).

Resultados

Aqui estão os resultados:

O trabalho desse projeto dbt corresponde a aproximadamente 97% de queries CTAS (modelos de tabela) e 3% de testes dbt (queries select simples).

Com base nisso, para os modelos de tabela do dbt neste projeto específico, o ganho de performance nem sempre é alto o suficiente para justificar os 35% de custo extra.

Vale notar também que o warehouse 4XL Gen2 teve um cold start bem longo, acima de 5 minutos, enquanto o 4XL Gen1 subiu de imediato. Como o tempo de retomada do warehouse não é cobrado, descontamos isso do resultado pré-iniciando o warehouse antes de rodar o dbt. Tempos de provisionamento geralmente não são um problema para jobs de ETL que rodam de madrugada, mas vale a observação.

Statements de select simples

Rodamos uma amostra de queries select dos datasets TPCH para simular o que aconteceria em uma ferramenta de BI ou em outras aplicações voltadas ao usuário. As queries exatas estão linkadas na tabela. Veja os resultados:

A query "Select, Aggregate" está aqui.

A query "Select, join, aggregate" está aqui.

Esses selects mostram ótimos ganhos de performance, e todos economizam dinheiro no Gen2 na base por segundo. Vale lembrar que, como essas queries voltadas ao usuário precisam ser rápidas, esbarramos na particularidade do período mínimo de cobrança do Snowflake. Se as queries rodam em menos de 60 segundos e/ou o warehouse fica ocioso por períodos longos (o que é comum em BI), o Gen1 segue como a melhor opção — a menos que você queira otimizar especificamente para velocidade e tenha fôlego para absorver o custo extra.

Outro ponto interessante: os Gen2 abrem a porta para reduzir o tamanho do seu warehouse. Por exemplo, se você corta os tempos de query pela metade com Gen2, mas o custo sobe porque o tempo ocioso fica mais caro, dá para reduzir o tamanho do warehouse pela metade, manter a mesma performance a um custo menor e ainda ter uma economia significativa.

DML: Update em tabelas grandes

Os updates desta seção são todos simples, no formato update table <tbl> set column <col> = value. Atenção: mesmo atualizando uma única coluna, o Snowflake precisa reescrever toda a micro-partição daquela linha. Na prática, esses dois comandos exigem a mesma quantidade de "trabalho" do Snowflake:

update orders_table set customer_id=5 where order_id=1;
update orders_table set customer_id=5, amount=22.05, order_date='2025-05-01',
<many columns>
where order_id=1;

Aqui rodamos três cenários:

• Um update sem cláusula where em 6 bilhões de linhas.
• Update seletivo na mesma tabela, atualizando apenas 2,4 milhões de linhas (0,04% da tabela).
• Update de uma única linha.
• Os statements SQL estão aqui.

Os resultados são bem conclusivos: os warehouses Gen2 vão muito bem em updates filtrados, provavelmente por conta das otimizações de software específicas que o Snowflake lançou.

Vamos olhar mais a fundo a query com -79% de delta de custo para entender de onde vem uma melhora tão grande.

O screenshot mostra uma redução de 99% nos bytes escritos!

(0,16 GB – 16,56 GB) / 16,56 GB = -99%

DML: Queries de merge

Setup

Diferente dos updates simples acima, as queries de Merge atualizam registros no destino com base em registros de uma origem. Nesse caso, um join é usado para atualizar registros que dão match e inserir os novos.

As queries de merge com n% das linhas atualizadas são modelos incrementais do dbt. Para rodá-las, executamos dbt run -s pre_merge+ e editamos o filtro de limite de linhas na linha 22. Isso simula uma situação real de incremental, em que só uma fração dos dados é nova ou atualizada. Para mudar o % de dados atualizados, alteramos esta linha e rodamos o modelo + o modelo incremental downstream.

As tarefas "Merge, todas as linhas atualizadas" vêm desta query, que atualiza todas as linhas do dataset.

Lembre-se: o dataset SF10 tem cerca de 60 milhões de linhas e o SF100, cerca de 600 milhões.

Resultados

Os resultados acima mostram, de forma conclusiva, que merges que atualizam poucos registros têm um ganho de performance maior do que merges sem restrição.

A evidência está no query profile, que revela alguns detalhes interessantes. Primeiro, a comunicação de rede caiu bastante, de 41% para 13%. Essa queda provavelmente se deve à redução drástica de bytes escritos — de 1,6 GB para apenas 4,65 MB. Isso sugere que o Snowflake pode ter melhorado a compressão ou otimizado a forma como os dados trafegam pela rede. Como as duas queries atualizam apenas 100 linhas, isso reforça a tese de que o Gen2 traz otimizações específicas para escrever dados de forma mais eficiente.

Uma anomalia

A única anomalia (na penúltima linha, com apenas 1% de economia) é bem curiosa, porque o Snowflake aponta que 99,5% menos bytes foram escritos. Algumas hipóteses possíveis incluem throttling do S3 e velocidade de rede.

Todos os resultados acima são apresentados na base por segundo. Mas, como mencionamos antes, o tempo ocioso depois que as queries terminam também conta. Vamos montar um cenário simples. Na tabela abaixo, assumimos que o Gen2 consegue rodar uma query em 50% menos tempo que o Gen1 — uma suposição bem generosa, mas vai servir. Vamos supor também que o auto-suspend está configurado para 60 segundos. O resultado seria:

Como era de se esperar, quanto mais longo o workload, menor é esse impacto. A tabela abaixo dá uma ideia de como esse efeito diminui conforme a duração da query aumenta:

Esse fenômeno pode ser expresso como uma função:

% tempo ocioso = [segundos de auto suspend] / ([Tempo da query] + [segundos de auto suspend])

Para clientes do Snowflake que estão otimizando para performance, o impacto do tempo ocioso é desprezível perto do custo de ter um data engineer ajustando queries manualmente — e queimando ainda mais créditos no processo! Mesmo assim, vale levar o tempo ocioso em conta.

Revisando os resultados agregados

Olhar para resultados agregados pode enganar, porque eles são fortemente influenciados pelo número de queries que rodamos em cada categoria e pelo tamanho do warehouse. Também escondem o fato de que queries específicas dentro de uma mesma categoria podem ter resultados muito diferentes do agregado.

Mesmo assim, ainda é útil olhar para os dados agregados — afinal, eles deixam claro que tanto a mudança de custo quanto a performance variam bastante.

Abaixo, você encontra os resultados dos testes acima, consolidados para facilitar a consulta.

A lição aqui é: sempre experimente com o seu dataset para ver como o Gen2 se sai nos seus casos de uso específicos. Como na maioria das coisas na nuvem, é muito difícil dizer qual ferramenta é universalmente mais barata ou melhor. Sempre depende do caso de uso.

Mas há alguns aprendizados centrais:

• Agora temos um botão de esforço zero para acelerar queries e, em geral, reduzir custo.
• As queries select simples estiveram entre as de melhor performance nos nossos testes, com 26% de economia no custo.
  • Por outro lado, podem sair mais caras se rodarem em warehouses não saturados por menos do que o período mínimo de cobrança.
  • Lembre-se: pode ser perfeitamente aceitável pagar 10% a mais (digamos, US$ 10 mil/ano extras) por uma melhora de 20% com esforço zero para todos os usuários de negócio. Pondere o trade-off de quanto tempo levaria para fazer essas otimizações na mão.
• O Gen2 é disparado melhor que o Gen1 para updates direcionados e queries select simples que envolvem full table scans.
• O Gen2 não é necessariamente mais barato para modelos de tabela dbt no caso médio. Isso provavelmente se deve à reescrita de todas as partições dos dados via "create or replace table as". Mas pode ser mais barato e mais rápido em modelos incrementais que usam statements de merge.

Um ótimo caso de uso para os warehouses Gen2 é quando o seu warehouse atual está estourando e você está pensando em subir de tamanho — digamos, de Medium para Large. Em vez de ir para Large, onde os créditos custam 100% a mais, experimente subir para Gen2 Medium e pagar só 35% a mais por crédito. Pessoalmente, comecei a pensar no Gen2 como um meio passo entre cada tamanho de warehouse.

• A economia total foi de 2% — mas esse número é fortemente puxado pelos dois maiores workloads.
• Excluindo os dois maiores consumidores de créditos, a economia total sobe para 7%.

Ao discutir nossos resultados de benchmark com alguém do Snowflake, ouvimos uma frase que ficou: "A única coisa que um benchmark te diz é a velocidade com que o próprio benchmark rodou". Há muitos fatores a considerar para entender o impacto disso no seu workload de produção.

• Falta de concorrência: benchmarks, na maior parte, rodam em warehouses não saturados, em que a concorrência não é um problema.
• Ruído transiente: a mesma query, rodada nas mesmas condições, pode variar cerca de 10% para mais ou para menos se for executada em outro momento, por conta da variabilidade natural da infraestrutura de nuvem (problemas transientes, throttling do AWS S3, etc).

Recomendamos rodar o Gen2 em workloads direcionados por um período, talvez uma semana, para ver o impacto real no custo do seu ambiente.

Na SELECT, queremos desenvolver uma abordagem mais robusta e científica para benchmarking. Imaginamos um cenário em que um script Python rode a mesma query várias vezes contra o mesmo dataset, em diferentes warehouses. Assim, conseguimos uma amostra maior, em que cada resultado individual pesa menos na média. Em breve, mais novidades!

Queremos muito saber da sua experiência com os warehouses Gen2! Entre em contato e compartilhe descobertas interessantes ou histórias de economia!

Jeff é Consultor de Dados e Analytics com mais de 15 anos de experiência em automatizar insights e usar dados para conduzir processos de negócio. Do lado técnico, é especializado em Snowflake + dbt + Tableau. Do lado de negócio, tem experiência em Serviço Público, Estudos Clínicos, Editorial, Bens de Consumo (CPG) e Manufatura. Fale com ele a qualquer hora: [email protected].

Ian Whitestone·Cofundador e CEO da SELECT

Ian é Cofundador e CEO da SELECT, uma plataforma SaaS de gestão e otimização de custos do Snowflake. Antes de fundar a SELECT, Ian passou 6 anos liderando times full stack de data science e engineering na Shopify e na Capital One. Na Shopify, foi responsável pelos esforços de otimização do data warehouse e pelo aumento da observabilidade de custos.