A escolha entre data lake e data warehouse começa pela pergunta de negócio, não pela ferramenta. Se a diretoria precisa das mesmas vinte respostas todo mês (receita por canal, margem por produto, churn por segmento), um warehouse gerenciado resolve e um lake só adiciona trabalho. Se a empresa precisa guardar logs, documentos, eventos de navegação e dados de sensores para perguntas que ainda não sabe fazer, o warehouse sozinho fica caro e apertado.
O que mudou nos últimos anos é que essas duas opções deixaram de ser excludentes. Hoje dá para guardar dado em formato aberto, em armazenamento barato de objetos, e consultá-lo com o motor do warehouse. Isso muda a decisão, mas não elimina a pergunta de partida.
A diferença que continua valendo
Um data warehouse guarda dado estruturado com esquema definido na escrita (schema-on-write): a tabela de vendas tem colunas, tipos e regras antes de receber a primeira linha. É otimizado para SQL, BI e perguntas recorrentes. BigQuery, Snowflake e Amazon Redshift são os exemplos mais comuns.
Um data lake guarda arquivos brutos em armazenamento de objetos (Amazon S3, Google Cloud Storage, Azure Data Lake Storage) e aplica o esquema na leitura (schema-on-read). Aceita CSV, JSON, Parquet, imagens, PDFs, logs. É barato para guardar e flexível para explorar, mas empurra o problema de qualidade e governança para quem consome.
O artigo que popularizou o termo lakehouse, publicado por Armbrust, Ghodsi, Xin e Zaharia no CIDR 2021, descreve bem o problema da arquitetura em duas camadas que muitas empresas montaram: o dado cai no lake, uma parte é copiada para o warehouse via ETL, e as duas cópias se desencontram. Os autores listam os custos dessa separação: dado desatualizado, falhas de confiabilidade entre as cópias, custo total mais alto, dependência de fornecedor e suporte limitado a ciência de dados.
O que o lakehouse mudou
A resposta técnica veio dos formatos abertos de tabela. Apache Iceberg e Delta Lake adicionam uma camada de metadados sobre arquivos Parquet no armazenamento de objetos, e com ela transações ACID, evolução de esquema, consulta a versões anteriores (time travel) e exclusão de linhas específicas. Na prática, o arquivo no bucket passa a se comportar como tabela.
Os três grandes warehouses de nuvem já leem esses formatos:
- A Snowflake colocou as tabelas Apache Iceberg em disponibilidade geral em junho de 2024.
- O Amazon Redshift consulta tabelas Iceberg catalogadas no AWS Glue, pelo Redshift Spectrum ou pelo Redshift Serverless.
- O BigQuery oferece tabelas BigLake para Apache Iceberg, com o dado em buckets do próprio cliente.
A consequência para quem decide: guardar dado em Iceberg ou Delta reduz o risco de ficar preso a um fornecedor, porque outro motor consegue ler a mesma cópia. O preço é mais uma peça para operar: catálogo, compactação de arquivos pequenos, política de retenção de snapshots. Em time pequeno, isso pesa.
O modelo de cobrança pesa tanto quanto a arquitetura
Muita decisão de dados dá errado na fatura, não no desenho. Os três fornecedores cobram de jeitos diferentes, e cada jeito pune um comportamento diferente.
BigQuery. No modelo on-demand, a cobrança é pelo volume de dados lido em cada consulta: o primeiro TiB do mês é gratuito, e a tabela de preços lista US$ 6,25 por TiB a partir daí em regiões como us-central1. Existe também o modelo por capacidade, em slots. O on-demand pune consulta que varre a tabela inteira: um painel mal feito que lê uma tabela grande a cada atualização vira linha relevante na fatura. Particionar por data e clusterizar pelas colunas mais filtradas costuma ser a primeira economia.
Snowflake. O processamento roda em virtual warehouses que consomem créditos cobrados por segundo, com mínimo de 60 segundos a cada vez que o warehouse liga. Aqui o que pesa é warehouse ligado sem uso e warehouse maior do que a carga pede. Auto-suspend curto e tamanhos separados para carga e para BI resolvem boa parte.
Redshift. Há clusters provisionados, em que você paga pelos nós ligados, e o Redshift Serverless, cobrado por capacidade usada (RPU-hora), por segundo, com mínimo de 60 segundos. A própria documentação da AWS alerta para um custo que surpreende: consultas de health check de pools de conexão, como um SELECT 1 periódico, são cobradas como uso normal. Uma aplicação que mantém conexões abertas pode gerar custo sem ninguém consultar nada.
Nenhum desses modelos é melhor em absoluto. Carga previsível e constante tende a sair mais barata com capacidade reservada; carga irregular, com picos no fechamento do mês, tende a favorecer on-demand ou serverless. Por isso vale medir o perfil de uso real antes de assinar compromisso anual.
Um checklist para decidir
Responda a estas perguntas antes de escolher tecnologia:
- Quais são as perguntas recorrentes? Liste as que a diretoria e as áreas fazem todo mês. Se todas saem de ERP, CRM e financeiro, você está no território do warehouse.
- Que tipos de dado entram? Só tabelas de sistemas transacionais, ou também eventos de site e app, logs, documentos, áudio, telemetria? Dado não estruturado em volume puxa para lake ou lakehouse.
- Quem consome? Analistas com SQL e ferramenta de BI, ou cientistas de dados com Python e Spark treinando modelos? O segundo grupo ganha com acesso direto a arquivos em formato aberto.
- Quem vai operar? Um lakehouse com Iceberg exige engenharia de dados de verdade. Se o time de dados é uma pessoa, um warehouse gerenciado é a escolha mais segura.
- Em que nuvem a empresa já está? Contrato, rede, identidade e segurança já configurados valem dinheiro. Quem está em Google Cloud tem um caminho curto até o BigQuery; quem está em AWS, até Redshift e Athena.
- Qual a tolerância a lock-in? Se a empresa quer poder trocar de motor em três anos, guardar em formato aberto desde já é barato agora e caro depois.
- Como você atende à LGPD? Um pedido de exclusão de dado pessoal precisa ser cumprido em todas as cópias. Num lake de arquivos soltos, achar e apagar um CPF é trabalho braçal; num warehouse ou numa tabela Iceberg ou Delta, é uma instrução DELETE.
Três cenários comuns
Empresa de médio porte com ERP, CRM e planilhas. Algumas centenas de gigabytes, perguntas conhecidas, time de dados pequeno. Warehouse gerenciado na nuvem que a empresa já usa, uma ferramenta de ingestão e uma camada de modelagem em SQL. Lake, aqui, é custo sem retorno.
Varejo digital com clickstream, catálogo e planos de recomendação. Eventos em volume alto, dado semiestruturado, cientistas de dados que precisam do histórico bruto. Armazenamento de objetos com tabelas Iceberg, lidas pelo warehouse para BI e por Spark ou Python para os modelos.
Indústria com sensores e sistemas legados. Telemetria de alta frequência que ninguém consulta inteira, mais dados de produção e qualidade que a gestão consulta todo dia. Telemetria bruta no lake, agregados por turno e por máquina no warehouse.
O erro mais caro
Migrar para data lake achando que isso resolve a bagunça dos dados. Se hoje ninguém sabe qual planilha tem o número certo de clientes ativos, um lake vai guardar todas as versões erradas, com muito mais espaço. O problema nesses casos é governança: dono para cada tabela importante, definição única das métricas, catálogo que diz de onde cada número vem. Nenhuma arquitetura substitui isso, e lake sem governança vira o que o mercado apelidou de data swamp.
Próximo passo
Antes de comparar fornecedores, reúna as dez perguntas que a diretoria mais faz e marque, para cada uma, de que sistema vem o dado e com que frequência a resposta precisa ser atualizada. Essa lista de uma página decide mais do que qualquer benchmark de desempenho, e mostra se o seu problema é arquitetura ou governança.
Se quiser ajuda para montar essa lista e transformá-la em arquitetura, é o trabalho que fazemos em Dados e IA. Quando a dúvida é pontual, como saber se vale migrar um warehouse para Iceberg, uma PoC Factory de poucas semanas mede custo e desempenho com os seus próprios dados.