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. 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.