A reunião que se repete em todo final de ano em empresa de médio porte: "vamos trocar de warehouse, mas qual escolher?". Sai consultoria com benchmark de query, vendedor com desconto, deck com gráfico de TCO. Em três meses, a decisão geralmente foi tomada — e em seis meses, metade das empresas se arrepende. Não porque escolheram o errado, mas porque resolveram o problema errado.
Snowflake, BigQuery e Databricks são, em 2026, funcionalmente equivalentes pra 80% dos casos de empresa brasileira de médio porte. Performance, custo médio, recursos básicos — todos passam. A escolha real não está na ferramenta isolada; está no que envolve cada uma. Esse texto é o critério honesto que a gente usa antes de assinar contrato de três anos.
O que ninguém te diz no pitch
Os três vêm com a mesma promessa: SQL escalável, separação compute/storage, governança, performance previsível. E entregam. Você pode rodar uma operação de médio porte (5–50 TB, 20–100 usuários técnicos) em qualquer um dos três e ter um warehouse que funciona.
Diferenças reais entre eles existem — mas são marginais nesse escopo. Snowflake tem UX mais polida e separação compute mais granular. BigQuery integra mais fácil com o resto do Google Cloud (e tem preço por query escaneada, não por compute reservado). Databricks tem o melhor stack pra ML/data science nativo e Delta Lake como formato aberto.
No tamanho médio porte, escolher entre Snowflake, BigQuery e Databricks lembra escolher entre Toyota, Honda e Mazda: todos chegam aonde você precisa. O critério não é a marca, é o que mora em volta — oficina, peças, hábito de manutenção.
Quem chegar pra você dizendo que um dos três é objetivamente melhor sem qualificar pelo seu contexto está vendendo, não comparando.
Quatro critérios que decidem de verdade
Os critérios que importam separam empresas que escolhem com clareza das que ficam paralisadas.
- Stack que já existe. Se a empresa já é Google Cloud-first (GA4, Looker, Vertex AI), BigQuery reduz fricção de integração em 80%. Se é AWS-first, Snowflake tende a ser default. Se já investiu em Spark/MLflow, Databricks fecha o ciclo. Empresa "stack agnóstica" não existe — sempre tem peso de algum lado. Identificar antes de decidir.
- Perfil do time atual. Time forte em SQL e BI vai render mais em Snowflake (UX otimizada pra esse perfil). Time com background em engenharia de dados e Python prospera em Databricks. Time que já roda em GCP achata curva no BigQuery. Tentar virar o perfil do time pra encaixar na ferramenta é o caminho mais caro de implantação.
- Roadmap de IA/ML real. Se o plano é só relatório + dashboard, qualquer um dos três serve. Se o plano envolve treinar modelos próprios, feature store, MLOps sério — Databricks tem 18 meses de vantagem em integração nativa. Se é só rodar LLM via API com RAG sobre dados do warehouse, qualquer um serve com plugins externos.
- Custo total honesto — não a tabela de preço. Os três publicam preços por crédito/hora/query. Nenhum desses números reflete o que sua empresa vai pagar de fato. O número real depende de padrão de uso (picos vs. constante), maturidade do time (queries otimizadas vs. queries soltas), governança (auto-suspend funcionando vs. cluster ligado domingo de manhã). Empresa que não calcula custo histórico de uso antes assina contrato e descobre fatura 2–3× maior no terceiro mês.
Quem responde os quatro com clareza sabe qual escolher. Quem responde "depende" em três ou mais ainda não tem caso de uso definido — e qualquer warehouse vai virar projeto eterno.
Onde cada um realmente brilha (e onde realmente pena)
Sem fugir do compromisso, três frases honestas sobre cada um:
Snowflake. Brilha em operação SQL pura com time de BI/analytics maduro. UX, separação de warehouses por workload, time travel são best-in-class. Pena em workloads de ML/data science nativo (precisa de integrações externas pra ter o que Databricks dá em casa) e em casos de federation de queries pesados.
BigQuery. Brilha em ecossistema Google (integração GA4, Vertex, Looker) e em modelo serverless real — você não dimensiona cluster. A combinação BigQuery + Looker é a mais integrada em plataforma pública, mas a escolha da ferramenta de BI — Looker, Power BI, Tableau ou Metabase — segue critérios de porte e stack separados do warehouse. Pena em previsibilidade de custo (modelo por query escaneada penaliza queries mal-escritas) e em UX menos polida que Snowflake pra time que vem de SQL clássico.
Databricks. Brilha em ML/data science nativo, suporte a Delta/Iceberg, pipelines streaming, notebooks colaborativos. Pena em complexidade — exige time mais técnico, e operações puramente analíticas (BI + dashboard) podem ser overkill. Curva de aprendizado é a mais íngreme dos três.
Nenhum desses "pena" é deal-breaker se o resto da equação encaixa. Mas saber onde dói antes de assinar é parte do trabalho de decisão.
A decisão que ninguém quer tomar — ficar onde está
A pergunta menos perguntada na reunião de warehouse: e se a gente ficar onde está?. Migração de warehouse custa entre 6 e 18 meses de equipe sênior, dependendo do volume e complexidade. Esse custo raramente entra no business case do "switch".
Vale calcular o que de fato muda com a troca. Se a resposta é "performance" e a empresa atual entrega queries em segundos, o ganho é marginal. Se é "ML/IA", checar se o gargalo real é o warehouse ou o time. Se é "custo", normalmente é problema de governança — vai aparecer no warehouse novo também.
A empresa que decide trocar sem entender essa conta migra duas vezes em três anos.
Um movimento honesto pra 2026
Pra empresa de médio porte brasileira em decisão real sobre warehouse, três movimentos práticos antes de qualquer assinatura:
POC pago de 30 dias com dado real. Não a demo do vendor — POC interno, com 2–3 casos de uso seus, equipe sua, queries suas. Os três vendors aceitam crédito promocional pra isso. POC mede o que folheto não mede.
Cálculo de custo histórico simulado. Pegar uso real do último trimestre (volume scaneado, número de queries, picos) e simular cada um dos três no preço público. Diferenças costumam ser de 30–50%, e raramente o "mais caro" do papel é o mais caro na prática.
Conversa com 2 clientes de cada um, do mesmo porte que você. Vendor te conecta. Se não conecta, péssimo sinal. Empresa de porte similar te diz em 30 minutos o que folheto esconde em 100 páginas.
Os três warehouses são produto maduro de empresa séria. A pior decisão é assinar pelo melhor pitch. A segunda pior é não decidir por seis meses por medo de errar. A melhor é entender que a sigla do warehouse importa menos do que como a modelagem é versionada em cima dele — e que modelagem dimensional bem feita continua valendo em 2026, independente da escolha de stack. (Pra quem quer o ângulo complementar — não qual é melhor, mas qual é mais caro abandonar — vale ler o exame de lock-in. E pra entender onde cada warehouse se encaixa no mapa do que sobreviveu do Modern Data Stack, a leitura complementa.) Antes de avaliar uma mudança para lakehouse, vale confirmar se os critérios de adoção realmente se aplicam.
Perguntas que sempre voltam
Antes de fechar, as três dúvidas que mais chegam quando essa decisão entra na pauta.
Vale a pena trocar de warehouse em 2026?
Na maioria dos casos, não — e essa é a conta que quase nunca entra no business case. Migração de warehouse custa de 6 a 18 meses de equipe sênior, e esse custo raramente aparece no deck do "switch". Se o motivo é performance e o warehouse atual já entrega queries em segundos, o ganho é marginal. Se é custo, o problema quase sempre é governança — e vai reaparecer no warehouse novo.
A troca faz sentido quando algum dos quatro critérios grita: stack já pesando pra um lado, perfil do time desalinhado da ferramenta, roadmap de IA/ML que o warehouse atual não cobre. Quem troca sem responder isso com clareza costuma migrar duas vezes em três anos.
Qual dos três é o mais barato?
Nenhum, em abstrato — o custo real depende do seu padrão de uso, não da tabela de preço. Os três publicam valores por crédito, hora ou query escaneada, e nenhum desses números reflete a fatura que vai chegar. O que decide é pico vs. uso constante, maturidade do time em otimizar queries e governança básica (auto-suspend funcionando faz diferença real).
O caminho prático: pegar o uso do último trimestre e simular os três no preço público. As diferenças costumam ficar entre 30 e 50%, e raramente o "mais caro" do papel é o mais caro na prática. Empresa que pula essa simulação descobre fatura 2–3× maior no terceiro mês.
Preciso do Databricks pra usar IA?
Não, se o plano é rodar LLM via API com RAG sobre dados do warehouse — qualquer um dos três resolve isso com plugins externos. O que muita empresa chama de "roadmap de IA" é exatamente esse cenário, e ele não justifica trocar de plataforma.
O Databricks vale a diferença quando o plano envolve treinar modelos próprios, feature store e MLOps sério — aí ele tem cerca de 18 meses de vantagem em integração nativa sobre os outros dois. A pergunta honesta antes de decidir é se o gargalo real é o warehouse ou o time.