Snowflake vs Databricks: o duelo

Os dados

Nosso benchmark usa o TCP-H com Scale Factor 1000. Esse conjunto de dados tem cerca de 6 bilhões de linhas na maior tabela. Snowflake e Databricks têm dados TPC-H, mas não em tamanhos equivalentes nem nos mesmos conjuntos grandes. Para fazer uma comparação justa, é preciso fazer ETL dos dados do Snowflake para o Databricks. O caminho mais fácil é usar uma ferramenta feita para isso, como a Estuary, ou você pode fazer por conta própria.

O Databricks vem com:

• tpcds_sf1 e sf1000
• tpch com 30 milhões de linhas. Isso é cerca de metade do tamanho do scale factor 10 do Snowflake, que tem 60 milhões de linhas.

O Snowflake vem com:

• tpcds_sf10 e 100
• tpch nos scale factors 1, 10, 100 e 1000

Sem surpresas, as plataformas dificultaram a comparação de performance ao não oferecer dados de amostra equivalentes. 🤨

Cenários

Usamos essas queries padrão em 3 cenários:

• Rodar todas as 22 queries sequencialmente. Nesse cenário, só a query 1 é um cold start; cada query seguinte pode aproveitar o cache do warehouse alimentado pelas anteriores.
• Rodar todas as 22 queries em paralelo. Aqui estamos testando a capacidade da plataforma de rodar várias queries ao mesmo tempo e observar se há algum escalonamento horizontal.
• 5 queries com cold start. Rodamos uma seleção menor de queries, com complexidade e estilo variados, para ver como as plataformas se comparam em um warehouse frio.

Workloads de CTAS: como as queries padrão do benchmark produzem resultados pequenos e na maioria altamente agregados, elas não eram um bom indicativo de um workload real de CTAS, porque o payload de escrita seria pequeno demais para estressar o throughput de escrita. Para testar operações intensivas em escrita, criamos 5 variantes que materializam grandes conjuntos de resultados em formatos diferentes, indo de tabelas estreitas com bilhões de linhas até tabelas desnormalizadas bem largas, o que permite comparar a performance de escrita em diferentes formatos de tabela e complexidades de query.

Workloads de DML: aqui deletamos 1 mês de dados da tabela e reinserimos. 1 mês representa cerca de 1% dos dados, ou 6 milhões de linhas. Isso testa tanto a eficiência do query pruning (mirando o 1 mês específico) quanto a eficiência do DML.

Warehouses

Cada run e cenário tem um warehouse novo gerado automaticamente no início do run + cenário, e o warehouse é destruído imediatamente quando o trabalho termina. Isso permite olhar o custo total de um warehouse de forma isolada e tirar o tempo ocioso da equação.

Um Databricks Serverless SQL Warehouse é mais ou menos equivalente a um Snowflake Warehouse de um tamanho acima. Por exemplo, um Small no Databricks equivale aproximadamente a um Medium no Snowflake. Rodamos os 4 cenários acima nestas combinações de warehouse:

• Snowflake Medium vs Databricks Small
• Snowflake Large vs Databricks Medium
• Snowflake XL vs Databricks Large

Essa comparação de tamanhos é corroborada pelas documentações do Snowflake e do Databricks, em que o Worker Count do Databricks é considerado igual aos Credits do Snowflake.

Atribuição de custo

Queríamos que a atribuição de custo fosse a mais precisa possível. Para isso, usamos warehouses isolados, como descrito acima. Usamos os dados reais de cobrança (em credits ou DBUs) durante a vida útil daquele warehouse. No fim, aplicamos uma calculadora de custo flexível para simular diferentes custos por credit ou por DBU nos resultados, representando tiers diferentes de plataforma. Com essa abordagem, eliminamos toda a complexidade da atribuição de custo para queries rodando em paralelo, incrementos mínimos de cobrança etc. Olhamos apenas o custo total do cenário.

Quando mostramos o custo de queries individuais em vez do run inteiro, ele é atribuído àquela query com base na proporção do seu tempo de execução. Basicamente, o custo total do run (ou da vida útil daquele warehouse) é distribuído entre as queries, então as contas fecham.

Comparação de custo

O Databricks Standard Tier está sendo descontinuado (e provavelmente já foi em outubro de 2025). Por isso, ao comparar o menor List Price de cada plataforma, a conta fica Snowflake Standard a US$ 2/credit vs Databricks Enterprise a US$ 0,70/DBU. Achamos essa uma comparação justa, já que o Snowflake Standard tier é uma versão completa do Snowflake, sendo o time travel a principal funcionalidade ausente. Mas entendemos que muitos leitores vão querer comparar Enterprise vs Enterprise. Por isso, vamos mostrar os dois: Databricks a US$ 0,70/DBU vs Snowflake a US$ 2/credit e a US$ 3/credit.

Histórico de runs e análise

Os IDs de query e as estatísticas dos runs são registrados imediatamente em um duckdb local. Os dados são armazenados na granularidade de ID de query (mais run ID, Warehouse e cenário). Views de relatório agregam os dados para que possamos tirar conclusões considerando runs inteiros.

Queries

As queries do benchmark podem ser encontradas aqui. (Embora o SQL pareça estar fixado no scale factor 100x, o nome da tabela é substituído dinamicamente em tempo de execução pelo scale factor do seu arquivo de configuração. Todos os testes foram rodados no scale factor 1000x.) Organizamos as 22 queries em categorias com base na complexidade e no número de joins. O detalhamento completo das categorias está aqui, mas este screenshot traz um resumo rápido.

Objetivo e configuração

Objetivo: rodar queries sequencialmente simula o que você sente sentado na sua mesa rodando queries nessas plataformas de dados. É o que os usuários finais experimentam ao executar uma query select. Essa medição permite comparar query por query, warehouse por warehouse, de forma parecida com a maioria dos benchmarks TPC-H.

Configuração: é simples ao extremo: rodamos 22 queries, uma de cada vez. Em todos os cenários, o warehouse é criado no início do run e destruído logo depois que a última query termina. Os resultados das queries são registrados imediatamente no duckdb.

Nesse cenário, só a query 1 é um "cold start" de verdade; as queries 2–22 são consideradas quentes, já que o warehouse fica ligado durante todo o run.

Resultados

Snowflake a US$ 2/Credit vs Databricks a US$ 0,70/DBU:

Snowflake a US$ 3/Credit vs Databricks a US$ 0,70/DBU:

Dá para ver que, a US$ 2/Credit, o Snowflake é 34% mais rápido e 17% mais barato. Subindo o Snowflake para US$ 3/credit, o Databricks fica 20% mais barato.

Objetivo e configuração

Objetivo: simular o carregamento de um dashboard de BI ou jobs em que dezenas de queries são disparadas de uma vez. A meta é testar como cada plataforma de dados lida com concorrência.

Configuração: usamos Python para disparar todas as 22 queries de uma vez e registrar os resultados.

Resultados

Snowflake a US$ 2/Credit vs Databricks a US$ 0,70/DBU:

Snowflake a US$ 3/Credit vs Databricks a US$ 0,70/DBU:

Nos dois cenários, o Snowflake foi mais rápido e mais barato! Ou seja, para workloads concorrentes, o Snowflake parece ser o vencedor (neste cenário de benchmark).

Mas agora vamos olhar como cada plataforma lidou com a concorrência. Se a concorrência fosse tratada de forma perfeita (sem fila nem competição por recursos), o tempo total de execução do teste em paralelo seria mais ou menos igual ao da query mais demorada rodando sozinha.

Plataforma	Tamanho do Warehouse	Query isolada mais longa	Wallclock simultâneo	Razão
Databricks	SMALL	134,5 seg	369,5 seg	2,7x
Databricks	MEDIUM	64,5 seg	296,0 seg	4,6x
Databricks	LARGE	32,9 seg	176,5 seg	5,4x
Snowflake	MEDIUM	94,7 seg	278,7 seg	2,9x
Snowflake	LARGE	45,2 seg	142,8 seg	3,2x
Snowflake	XLARGE	20,7 seg	99,7 seg	4,8x

Os dados acima mostram que, nas duas plataformas, há uma penalidade ao rodar queries concorrentes (rodar várias ao mesmo tempo deixa todas mais lentas, ou há enfileiramento), mas o Snowflake tem a melhor razão nessa comparação.

Rodando 22 queries em paralelo, dá para ver que o Snowflake escalou até 4 clusters no Medium e no Large, e usou só 3 clusters no XL. Foi por isso que o XL custou só alguns centavos a mais que o Large.

Infelizmente, o mesmo dado não está disponível no Databricks. Não consegui descobrir uma forma de saber quantos clusters foram utilizados.

Objetivo e configuração

Objetivos: medir os tempos de execução das queries sem o "cache do warehouse" e ver se o tempo de startup do warehouse impacta os resultados.

As duas plataformas usam "cache do warehouse" ou "Photon acceleration", um cache que vive na VM que está rodando a query. Quando se rodam queries sequencialmente, a query 2 pode aproveitar parte do cache gerado pela query 1, e assim por diante.

Configuração: para ver como as queries se comportam quando não há cache disponível, desenhamos um cenário que desliga o warehouse entre cada execução. Aqui, decidimos não rodar todas as 22 queries, pois isso geraria muito gasto desnecessário.

O tempo de criação do warehouse não é contado no wallclock total, mas o tempo de startup do warehouse É contado no wallclock total.

As queries

Query	Categoria	Complexidade	Descrição
Q1	Agregação e filtragem simples	Baixa (aquecimento)	Múltiplas agregações (SUM, AVG, COUNT) com GROUP BY em tabela de 600M de linhas
Q3	Joins básicos (2-4 tabelas)	Média (OLAP padrão)	Join de 3 vias com agregação e filtro por data
Q5	Joins complexos (5+ tabelas)	Alta (teste de estresse)	Join de 6 vias com cálculo de receita e filtro geográfico
Q10	Joins básicos (2-4 tabelas)	Média (OLAP padrão)	Join de 4 vias com filtro seletivo e GROUP BY de alta cardinalidade
Q18	Subqueries e semi-joins	Média (OLAP padrão)	Subquery com IN e filtro de agregação (HAVING)

Query Categoria Complexidade Descrição Q1 Agregação e filtragem simples Baixa (aquecimento) Múltiplas agregações (SUM, AVG, COUNT) com GROUP BY em tabela de 600M de linhas Q3 Joins básicos (2-4 tabelas) Média (OLAP padrão) Join de 3 vias com agregação e filtro por data Q5 Joins complexos (5+ tabelas) Alta (teste de estresse) Join de 6 vias com cálculo de receita e filtro geográfico Q10 Joins básicos (2-4 tabelas) Média (OLAP padrão) Join de 4 vias com filtro seletivo e GROUP BY de alta cardinalidade Q18 Subqueries e semi-joins Média (OLAP padrão) Subquery com IN e filtro de agregação (HAVING)

Resultados

Aqui dá para ver que o Snowflake foi ordens de magnitude mais rápido e um pouco mais barato.

Olhando os detalhes, descobrimos que o tempo de startup do Databricks foi de cerca de 7 segundos por inicialização, enquanto o do Snowflake ficou abaixo de 1 segundo em todos os casos.

Objetivo e configuração

Objetivo: medir operações intensivas em escrita, típicas de tarefas de engenharia de dados e projetos dbt. As queries padrão do TPC-H são otimizadas para leituras analíticas; elas varrem grandes conjuntos de dados, mas retornam resultados pequenos e agregados (somas, médias, listas top-N). Isso testa execução e otimização de queries, mas não estressa a performance de escrita. Queríamos entender como Snowflake e Databricks se comparam ao escrever bilhões de linhas com formatos de dados variados.

Configuração: criamos 5 variantes de CTAS, cada uma desenhada para testar um padrão específico de escrita:

1. Estreita e alta (6B linhas × 4 colunas): uma projeção simples da tabela LINEITEM com apenas 4 colunas-chave (l_orderkey, l_partkey, l_quantity, l_extendedprice). Testa o throughput máximo de linhas com sobrecarga mínima de colunas.
2. Padrão e alta (6B linhas × 16 colunas): uma cópia completa da tabela LINEITEM (SELECT * FROM LINEITEM). Representa um padrão comum de duplicar ou arquivar grandes tabelas fato. (Normalmente, você usaria Clone para isso, mas hoje não estamos avaliando operações de Clone.)
3. Média e larga (1,5B linhas × 30 colunas): um join das tabelas ORDERS, CUSTOMER, NATION e REGION. Testa a combinação de performance de leitura e escrita com complexidade moderada de JOIN e um schema mais largo, típico de desnormalização de star schema.
4. Muito larga (6B linhas × 59 colunas): um join totalmente desnormalizado entre todas as tabelas TPC-H (LINEITEM, ORDERS, CUSTOMER, SUPPLIER, PART, PARTSUPP, NATION, REGION). Representa o caso extremo de tabelas largas e pré-juntadas, comum em camadas de analytics.
5. Filtrada (2B linhas × 16 colunas): LINEITEM filtrada por pedidos enviados após 1995 (WHERE l_shipdate >= '1995-01-01'). Testa o throughput de escrita para cópias parciais de tabelas, padrão comum em pipelines de dados incrementais.

Resultados

Snowflake a US$ 2/Credit vs Databricks a US$ 0,70/DBU:

Snowflake a US$ 3/Credit vs Databricks a US$ 0,70/DBU:

Snowflake a US$ 2/Credit vs Databricks a US$ 0,70/DBU, excluindo a query outlier "Muito larga":

Snowflake a US$ 3/Credit vs Databricks a US$ 0,70/DBU, excluindo a query outlier "Muito larga":

Dá para afirmar que, neste cenário de benchmark, o Databricks tem uma vantagem clara na criação de tabelas grandes via CTAS.

Objetivo e configuração

Objetivo: Delete + Insert é um padrão comum para atualizar dados de forma incremental. É a forma mais eficaz de transformar segmentos específicos de dados em tabelas grandes e, por isso, um cenário importante para testar.

Configuração: no início do run, é criada uma cópia dos dados de origem do benchmark. Isso não entra no tempo de execução nem nas métricas de custo. Depois que a cópia é criada, o processo de benchmark começa. Ele deleta 1 mês de dados, cerca de 6M de linhas ou aproximadamente 1% do total. Em seguida, reinsere o mesmo mês a partir da origem. Isso simula um cenário real de ETL em que registros correspondentes são deletados e reinseridos. Observação: não usamos merge porque é amplamente conhecido que delete + insert supera o merge.

Resultados

Snowflake a US$ 2/Credit vs Databricks a US$ 0,70/DBU:

Snowflake a US$ 3/Credit vs Databricks a US$ 0,70/DBU:

Os resultados aqui são bem interessantes. O motivo pelo qual o Snowflake M, L e XL processam os dados em menos de 20 segundos é o excelente query pruning. Os 6 bilhões de linhas são reduzidos para o equivalente a 6 milhões, então a operação acontece sobre um conjunto de dados bem menor. O Snowflake Small leva mais do que o dobro do tempo porque sofre spillage tanto na etapa de delete quanto na de insert.

O mesmo acontece no Databricks. Vemos uma concentração entre 35 e 39 segundos para todos os tamanhos de warehouse. O Databricks também reduz efetivamente o tamanho do dataset, então M, L e XL dão conta sem problemas. Só que não tão rápido quanto o Snowflake.

Se você quiser rodar esses testes por conta própria, é relativamente fácil. Como mencionado, a primeira coisa que você precisa fazer é o ETL do conjunto de dados 1000x do Snowflake para o Databricks. Essa é a parte difícil, e a única para a qual não estamos fornecendo automação, já que há variáveis demais em jogo. De novo, recomendo usar a Estuary para isso!

Com os dados disponíveis na sua conta Databricks, é só seguir o guia de introdução aqui. Basta ter o UV e o Snowflake CLI instalados, configurar seu arquivo .env rodando uv run setup_config.py, e pronto: já dá para começar a rodar benchmarks! O readme traz vários exemplos de como rodar cenários específicos, tamanhos de warehouse ou simplesmente rodar tudo de uma vez.

Depois que o benchmark roda, você precisa esperar 2 horas para os dados de cobrança se estabilizarem. Aí é só rodar uv run enrich.py para enriquecer os resultados com os dados de cobrança. Quando estiver pronto para visualizar os resultados, basta seguir os passos do readme também.

Os resultados mostram, de forma conclusiva, que o Snowflake Standard Edition é a plataforma mais custo-efetiva em todos os cenários, com exceção do CTAS, em que o Databricks supera o Snowflake tanto em custo quanto em performance. Subir para o Snowflake Enterprise Edition a US$ 3/credit deixa o Databricks mais barato em alguns cenários. De novo, benchmarks são só benchmarks, então não deixe de testar com os seus próprios dados!

Jeff é Consultor de Dados e Analytics, com mais de 15 anos de experiência em automatizar insights e usar dados para controlar processos de negócio. No lado técnico, é especialista em Snowflake + dbt + Tableau. No lado de negócios, tem experiência em Utilidades Públicas, Estudos Clínicos, Publishing, CPG e Manufatura. Entre em contato quando quiser: [email protected].