Data lake vs data warehouse: qual a diferença e qual usar

Uma distribuidora de médio porte decide “se preparar para a IA” e contrata um data lake. Oito meses depois, o lago tem dois anos de exportações do ERP, logs do site e arquivos que ninguém lembra quem subiu. O relatório de margem por cliente continua saindo de uma planilha, feita à mão, toda segunda.

A discussão data lake vs data warehouse costuma começar pelo lado errado: qual tecnologia é mais moderna, qual aguenta mais volume. Para a maioria das empresas brasileiras de pequeno e médio porte, a pergunta útil é outra: quem vai organizar esse dado, e quando?

A diferença entre data lake e data warehouse está no momento em que o dado é organizado. O data warehouse recebe dados limpos e estruturados para responder perguntas conhecidas, com SQL e relatórios. O data lake guarda tudo em formato bruto, a baixo custo, e só dá estrutura na hora de usar.

Qual a diferença entre data lake e data warehouse na prática?

Os dois guardam dados de várias fontes em um lugar só. O que muda é onde fica o trabalho. No data warehouse, você define antes o formato de cada tabela e o dado passa por um processo de ETL para entrar. Na documentação técnica, isso se chama schema-on-write. No data lake, entra qualquer coisa do jeito que veio, e a estrutura é aplicada na leitura: schema-on-read.

Parece um detalhe de engenharia, mas decide quem consegue usar o dado. O trabalho de organizar não desaparece no lake. Ele só muda de lugar e passa a ser pago a cada pergunta nova, em geral por alguém que sabe programar.

Critério	Data warehouse	Data lake
Tipo de dado	Tabelas estruturadas	Qualquer um: tabelas, JSON, logs, imagem, áudio
Quando organiza	Antes de guardar	Na hora de usar
Quem usa	Analistas e gestores, via SQL e BI	Engenheiros e cientistas de dados
Melhor para	Relatórios, KPIs, comparação de períodos	Treinar modelos, explorar dado sem uso definido
Risco típico	Rigidez: mudar o modelo dá trabalho	Virar depósito que ninguém consegue consultar

O data lake é mesmo mais barato?

Essa é a justificativa mais repetida, e ela envelheceu mal para quem tem pouco volume. Compare a lista de preços do Google Cloud na região de Iowa, consultada em novembro de 2026. O BigQuery, um data warehouse, cobra cerca de US$ 0,023 por GiB ao mês no armazenamento ativo. O Cloud Storage, base típica de um data lake, cobra cerca de US$ 0,02 na classe Standard.

Em 1 TB, são US$ 23 contra US$ 20 por mês. Uma diferença de três dólares não justifica uma decisão de arquitetura. O lake só fica bem mais barato em classes frias, como a Coldline, a cerca de US$ 0,004 por GiB, pensadas para dado que quase nunca é lido. E esse é o ponto: dado frio não responde a pergunta de ninguém.

Veja uma simulação de warehouse para um e-commerce com 40 GiB de histórico. São 30 GiB pagos em armazenamento, porque os 10 primeiros são gratuitos: US$ 0,69 por mês. Os dashboards fazem 40 consultas por dia, cada uma lendo 2 GiB, o que dá cerca de 2,3 TiB por mês. Descontado 1 TiB gratuito, sobram 1,3 TiB a US$ 6,25: uns US$ 8,40. Total perto de US$ 9 por mês.

Os números são um exemplo, não uma média de mercado, e os preços variam por região. Mas mostram onde está o custo de verdade: nas pessoas. Quem paga caro em dados, nesse porte, paga em horas de quem monta a carga e conserta o que quebra. Por isso a conta certa compara quanto tempo cada opção consome do seu time, não o preço do gigabyte.

Por que tanto data lake vira um pântano de dados?

O termo em inglês é data swamp: o lake que acumula arquivos sem dono, sem descrição e sem controle de versão. O motivo é simples. Guardar não dá trabalho, então ninguém decide o que entra. Seis meses depois, existem três arquivos chamados “clientes_final” e nenhuma pessoa sabe qual vale.

A promessa de “guardar tudo agora e decidir depois” soa prudente, mas costuma adiar a decisão difícil, que é definir o que é um cliente ativo ou como se calcula a receita. Sem essas definições, o problema de qualidade só fica armazenado com mais conforto. E o lake também não resolve dados em silos por conta própria: colocar tudo no mesmo balde não faz as tabelas conversarem.

Evitar o pântano exige três coisas: catálogo do que existe, um dono por conjunto de dados e uma regra de retenção. Se a empresa não tem quem cuide disso, ainda não tem condição de manter um lake.

Qual dos dois sua empresa precisa?

Na prática, a maioria das PMEs que chegou ao limite da planilha precisa de um data warehouse pequeno, e talvez nunca de um data lake. Vendas, mídia paga, CRM e financeiro são dados tabulares. Cabem em tabelas e as perguntas são conhecidas: quanto vendi, qual canal deu retorno, qual cliente sumiu.

O lake passa a fazer sentido quando o dado não cabe em tabela e alguém vai trabalhar nele. Uma rede de clínicas que quer analisar milhares de ligações gravadas, ou uma indústria com sensores gerando leitura a cada segundo, tem um caso real. Mesmo assim, é raro o lake substituir o warehouse: o resultado do processamento costuma terminar em tabelas para o gestor consultar.

Repare na terceira pergunta. Ter o dado bruto não basta: sem alguém para trabalhá-lo, a saída honesta é guardar uma cópia barata como seguro e seguir com o warehouse. Essa escolha custa pouco e pode ser revista depois, sem migração dolorosa.

O lakehouse substitui os dois?

Lakehouse é a tentativa de juntar os mundos: arquivos baratos no armazenamento de um lake, com uma camada que oferece tabelas e SQL como um warehouse. Faz sentido técnico, mas não mudou a ordem das prioridades. O relatório de 2026 da Dresner Advisory Services conclui que nenhuma arquitetura domina: o data warehouse é o preferido de 54% dos respondentes, e o lakehouse aparece com 29% de adoção. A adoção de data lake sobe de 42% para 62% conforme as empresas avançam em maturidade de IA.

Esse último número merece atenção, e não pelo motivo óbvio. O lake cresce onde já existe capacidade de IA, e não o contrário. Comprar um lake não produz maturidade. Para uma PME, lakehouse é um assunto para quando houver engenharia de dados dedicada. Antes disso, ele acrescenta complexidade sem resolver uma dor concreta.

Como começar sem errar a ordem

1. Liste as dez perguntas que o negócio faz todo mês e quais sistemas respondem cada uma.
2. Escreva as definições que dão briga: receita, cliente ativo, lead qualificado.
3. Conecte só as fontes dessas perguntas em um warehouse gerenciado, sem servidor para administrar.
4. Use uma ferramenta de carga pronta antes de pensar em escrever código próprio.
5. Avalie um lake apenas quando surgir um dado que não cabe nesse modelo e alguém com tempo para trabalhá-lo.

Perguntas frequentes

Data lake e data warehouse podem coexistir?

Sim, e em empresas maiores é o arranjo comum. O lake recebe o dado bruto e o warehouse guarda a versão tratada para consulta. Só não vale montar os dois ao mesmo tempo sem necessidade, porque você dobra a manutenção.

O que é melhor para inteligência artificial?

Depende do tipo de IA. Treinar modelos próprios com texto, imagem ou áudio pede um lake. Fazer perguntas sobre vendas e campanhas pede dado organizado e bem definido, ou seja, um warehouse. Modelo de linguagem lendo tabela confusa erra com muita confiança.

Excel ou Google Sheets podem ser um data warehouse?

Não. Planilha serve para análise pontual, mas não preserva histórico de forma confiável nem tem controle de carga. Para duas fontes e poucas linhas, porém, ela pode bastar por um bom tempo.

O que é ETL e ELT nesse contexto?

No ETL, o dado é transformado antes de entrar no destino, padrão clássico do warehouse. No ELT, ele entra bruto e é transformado depois, dentro da própria plataforma. O ELT ficou comum porque warehouses em nuvem têm processamento de sobra, e isso aproximou os dois mundos.

Comece pela pergunta, não pela arquitetura

Quem escolhe infraestrutura antes de saber o que quer perguntar quase sempre acaba com um projeto bonito e a mesma planilha de segunda-feira. Data warehouse é a escolha padrão de quem tem perguntas de negócio; data lake é uma resposta a um problema específico, que muita empresa ainda não tem. E em vários casos nem o warehouse é o primeiro passo: se a dor é cruzar mídia, CRM e planilhas para responder perguntas do dia a dia, o Sherlok conecta essas fontes e entrega a análise pronta a partir de uma pergunta em português, sem projeto de infraestrutura.