O gerente financeiro de uma empresa de logística em São Paulo passou três sextas-feiras seguidas reconciliando manualmente os dados do ERP com o CRM. O ERP dizia que um cliente estava inadimplente. O CRM mostrava o contrato como ativo. A planilha do analista tinha um terceiro número. Ninguém sabia qual era o real. Na quarta sexta-feira, alguém sugeriu "implementar um data warehouse". O projeto custou R$ 280.000, levou oito meses e o problema continuou existindo, porque a causa era dado duplicado na origem, não falta de infraestrutura.
Esse é o padrão que se repete. A solução de dados mais cara nem sempre é a que resolve o problema.
O que é um data warehouse sem enrolação: o lugar onde os dados de vários sistemas se encontram
Um data warehouse é um banco de dados separado dos seus sistemas operacionais. Ele existe para receber dados do ERP, do CRM, do sistema de estoque, do financeiro, e deixar tudo no mesmo lugar, com a mesma estrutura, pronto para consulta analítica.
O conceito é simples. O que complica é o que fica entre o sistema de origem e o warehouse: o processo de ETL (extração, transformação e carga). É aqui que alguém precisa escrever código para puxar dados do ERP toda noite, limpar inconsistências, mapear campos que têm nomes diferentes em cada sistema, e garantir que o processo não quebre quando o fornecedor do ERP lança uma atualização. Quando um fornecedor de ERP lançou uma atualização de schema, as empresas com ETL customizado chegaram na segunda-feira com quatro dias de dados faltando e nenhum relatório gerado. O risco é real e tem custo.
Esse "alguém" tem nome, cargo e salário. No Brasil, um engenheiro de dados sênior cobra entre R$ 18.000 e R$ 25.000 por mês. E você vai precisar de pelo menos um deles em tempo integral se quiser um warehouse funcionando de verdade.
O problema que ele resolve: quando ERP, CRM e planilha nunca batem
O problema que justifica um data warehouse tem uma forma específica: você tem dois ou mais sistemas que precisam conversar, essa conversa precisa acontecer com frequência, e os dados de um afetam decisões baseadas no outro.
Um distribuidor com filiais em quatro estados. O ERP registra as vendas por CNPJ do cliente. O CRM registra por nome fantasia. O sistema de metas da equipe comercial usa um código interno. Quando o diretor quer saber qual vendedor bateu meta em qual cliente naquele trimestre, ninguém consegue responder sem passar horas cruzando planilhas manualmente. Esse é o problema que um data warehouse resolve.
O que ele não resolve: dado errado na origem, processo mal desenhado, ou a simples falta de disciplina para preencher o CRM corretamente. Nenhuma infraestrutura de dados conserta problema de processo.
A maioria das PMEs não precisa de um data warehouse agora, e tudo bem
Apenas 30% das micro e pequenas empresas brasileiras usam dados para análise, segundo a Pesquisa de Maturidade Digital dos Pequenos Negócios 2024, do Sebrae/PR. Entre MEIs, esse número cai para 17%. O Índice de Maturidade Digital médio das pequenas empresas chegou a 37 pontos em 2025, numa escala até 80, com dois terços dos negócios concentrados entre os níveis baixo e médio.
Isso não é crítica. É contexto. A maioria das PMEs brasileiras está no estágio em que o problema não é infraestrutura de dados, é consistência de dados. E consistência se resolve com disciplina de processo e, no máximo, uma integração simples entre sistemas.
Se você tem um único ERP como fonte de verdade sobre vendas, estoque e financeiro, e precisa apenas visualizar esses dados num dashboard, você não precisa de um data warehouse. Você precisa de uma conexão direta do seu ERP ao Power BI ou ao Looker Studio. Isso resolve o problema em dias, não em meses, e custa uma fração do preço.
O CRM e o financeiro vivem em silos? Na maioria dos casos, o que parece problema de dados é problema de sincronização. Uma automação no Zapier ou no Make, configurada em duas horas e com custo abaixo de R$ 300/mês, resolve quando a integração entre os dois sistemas se resume a "quando o cliente paga, atualizar o status no CRM". Funciona bem para empresas com até 500 transações por mês e sem necessidade de análise histórica complexa.
A recomendação de data warehouse para quem não precisa dele não vem necessariamente de má intenção. Uma explicação provável é que consultorias têm incentivo em vender projetos maiores, e que a narrativa de "maturidade digital" trata o warehouse como um destino inevitável. Não é.
O sinal de que você realmente precisa: mais de dois sistemas cruzando dados com frequência
Existe um critério objetivo para saber se chegou a hora. Você precisa de um data warehouse quando:
Dois ou mais sistemas de origens diferentes precisam cruzar dados de forma recorrente, e esse cruzamento não pode ser feito manualmente nem com uma integração simples.
"Dois ou mais sistemas de origens diferentes" significa fontes que não se falam nativamente. ERP de um fornecedor, CRM de outro, plataforma de e-commerce de um terceiro. Se todos os seus dados vivem no mesmo sistema, não existe problema de warehouse.
"Cruzar dados de forma recorrente" significa que você precisa desse cruzamento toda semana, toda semana, não uma vez por trimestre para uma reunião de board. Se é uma análise pontual, uma query bem escrita num banco transacional resolve.
O terceiro critério é o filtro final e o mais prático. Antes de fechar a decisão, cheque: existe integração nativa entre os dois sistemas? O resultado cabe numa planilha com fórmulas PROCV? Se sim para qualquer um dos dois, warehouse ainda não é a resposta. O data warehouse só faz sentido quando essas alternativas já falharam ou claramente não vão funcionar na escala que você opera.
Uma empresa de serviços com 80 funcionários, que usa ERP para faturamento, CRM para pipeline de vendas e um sistema de gestão de projetos para alocação de horas, precisa saber mensalmente qual cliente é mais rentável considerando horas alocadas, receita faturada e custo de pessoal. Três sistemas, cruzamento recorrente, inviável manualmente. Esse é o cenário que justifica um data warehouse ou algo equivalente.
O que usar no lugar quando não é a hora: opções práticas e baratas
Antes de decidir por um warehouse, vale conhecer o que existe antes dele.
Power BI conectado direto ao banco do ERP via ODBC
O Power BI Pro custa R$ 80 por usuário por mês no Brasil. A ferramenta conecta diretamente a bancos MySQL, PostgreSQL e fontes ODBC sem precisar de nenhuma camada intermediária. Se o seu ERP roda em banco de dados acessível, um analista configura a conexão em um dia e você tem um dashboard funcional pagando menos de R$ 500/mês para seis usuários. Zero de infraestrutura de warehouse.
O limite dessa abordagem é performance. Uma query analítica pesada rodando direto no banco transacional do ERP em horário de pico pode travar o sistema operacional. Se isso acontece, você precisa de uma réplica de leitura, não necessariamente de um warehouse completo.
Zapier ou Make integrando CRM e financeiro
Quando um pagamento é confirmado no Stripe, o Zapier cria uma linha numa planilha Google e atualiza o status no Pipedrive automaticamente. Configuração: duas horas. Custo: menos de R$ 300/mês. Funciona bem para empresas com até 500 transações por mês e sem necessidade de análise histórica complexa.
Essa solução não substitui um warehouse para análises sofisticadas. Ela resolve o problema de sincronização operacional que muita empresa confunde com problema de analytics.
Google Looker Studio apontando direto para MySQL do ERP
O Looker Studio é gratuito e conecta a bancos MySQL via conectores como o CData Connect. Dashboard ao vivo, sem ETL, sem engenheiro de dados, sem custo de infraestrutura. O limite prático é o mesmo do Power BI: performance em horário de pico e ausência de cruzamento de múltiplas fontes.
Para uma empresa com uma fonte de dados principal e necessidade de visualização básica, essa combinação resolve o problema sem projeto de seis meses.
Quanto custa um data warehouse real para PME: SaaS, cloud e consultoria
Se depois de tudo isso o cenário da sua empresa ainda justifica um data warehouse, você precisa saber o que está comprando.
Em cloud, o custo de 10 TB de dados ao longo de três anos varia bastante por plataforma: BigQuery fica em torno de US$ 29.000, o Redshift em US$ 63.000, e o Snowflake em US$ 124.000. São números de referência internacional, mas a ordem de grandeza serve.
O que esses números não incluem é o custo do stack completo. ETL, compute, armazenamento, monitoramento, alertas, documentação. Quando você soma tudo, o custo mensal de um warehouse em nuvem operado corretamente começa em US$ 5.000 e chega facilmente a US$ 25.000/mês dependendo do volume.
Sem governança, os custos escalam rápido. Uma startup brasileira que começou com um warehouse no BigQuery viu a conta subir de R$ 10.000/mês para R$ 75.000/mês em seis meses. O motivo: proliferação de schemas e queries mal otimizadas rodando sem controle. O mesmo padrão apareceu em outros dois clientes que atendemos: sem governança de queries, o custo dobra em menos de seis meses.
Do lado de consultoria, um projeto de data warehouse com escopo fixo custa entre US$ 25.000 e US$ 150.000 dependendo da complexidade. Retainers contínuos de engenharia de dados custam entre US$ 8.000 e US$ 25.000 por mês.
Se a opção for internalizar a operação, o custo muda de natureza. No Brasil, o salário de um engenheiro de dados sênior está entre R$ 18.000 e R$ 25.000 mensais, fora encargos. Com um profissional sênior e os encargos trabalhistas, você está falando de R$ 35.000 a R$ 45.000/mês.
A conta não é intimidação: é o que separa uma decisão informada de um projeto que explode no meio do caminho. Quando o problema que o warehouse resolve vale mais do que esses custos, ele compensa. Mas essa matemática precisa fechar antes de assinar qualquer proposta.
Como tomar essa decisão sem depender de um vendedor de tecnologia
O conflito de interesse é real. Das propostas de implementação que analisamos para clientes em 2024, a maioria recomendava warehouse como solução, independente do porte e da real necessidade do negócio. Consultores de dados ganham mais em projetos maiores. Fornecedores de plataforma ganham com volume de uso. Nenhum deles tem incentivo em te dizer que você não precisa de um warehouse.
Então você precisa de uma forma de checar por conta própria.
Comece com uma conta simples: quantas fontes de dados diferentes precisam aparecer juntas numa análise que você toma toda semana? Se a resposta é uma ou nenhuma, pare aqui. Você provavelmente não precisa de warehouse.
Se é duas ou mais, a segunda pergunta é se esse cruzamento hoje é feito manualmente. Com qual frequência? Por quanto tempo? Se alguém passa mais de quatro horas por semana cruzando dados que deveriam estar integrados, você tem um problema real. A pergunta seguinte é se esse problema é de integração simples ou de analytics complexo.
Por último, considere onde está o gargalo real: o seu negócio teria mais impacto com dados mais rápidos ou com decisões melhores a partir dos dados que você já tem? Quem responde "dados mais rápidos" quase sempre tem gargalo no pipeline, não falta de warehouse. Quem responde "decisões melhores" tem problema de cultura analítica: e isso nenhuma plataforma resolve por você.
Se depois dessas três perguntas o cenário ainda apontar para um warehouse, aí vale avançar para a discussão técnica: qual plataforma, qual arquitetura, qual equipe. Mas essa é a segunda conversa, não a primeira.