Data Lake vs Data Warehouse: Principais Diferenças

Qual é a diferença entre um data lake e um data warehouse?

Um data lake armazena dados brutos no formato original e aplica estrutura só quando alguém os lê. Um data warehouse armazena dados que já foram limpos e modelados, e responde consultas SQL para relatórios e dashboards.

Um lake aceita dados estruturados, semiestruturados e não estruturados sem nenhuma mudança antes de salvar. Eventos JSON brutos de um app ou leituras de sensores IoT são dados típicos de lake. Um warehouse guarda uma versão curada desses dados: tabelas de vendas limpas, unidas e modeladas, prontas para um dashboard.

A ordem de processamento também é diferente. Os dados normalmente passam por limpeza e estruturação antes de entrar em um warehouse, enquanto um lake armazena primeiro e deixa você processar depois, ou nunca.

Como schema, tipos de dados, usuários e performance se comparam?

Um lake é schema-on-read, barato de armazenar e voltado a código. Um warehouse é schema-on-write, mais caro por terabyte e feito para SQL rápido. Esta é a comparação padrão:

Essas linhas descrevem como cada sistema costuma ser operado, e nenhuma delas é um limite rígido de produto. A própria comparação da AWS diz que o schema de um warehouse pode ser schema-on-write ou schema-on-read, e warehouses modernos carregam dados semiestruturados como JSON sem problema. As diferenças reais na prática são quem consulta o sistema, o quão governados os dados são e o que a conta mede.

Tabela de comparação da própria AWS entre data warehouse e data lake

O Amazon S3 é um data lake?

O Amazon S3 sozinho é object storage. Ele vira um data lake quando você adiciona as peças ao redor: pipelines de ingestão, um formato de tabela ou catálogo, uma engine de consulta e segurança e governança. Um bucket cheio de arquivos sem nada disso é só um bucket cheio de arquivos.

Uma versão concreta desse stack: a Erathos carrega dados de origem no S3 como arquivos Parquet em tabelas Iceberg, com particionamento automático e evolução de schema. Athena, Spark, Trino ou qualquer outra engine de consulta pode ler essas tabelas. O armazenamento é S3 puro; o formato de tabela e o pipeline são o que o tornam um lake.

Quando usar um data lake, um data warehouse ou os dois?

Um lake serve quando você tem muitos dados brutos e variados e quer explorá-los com código ou treinar modelos com eles. Um warehouse serve quando você tem perguntas de negócio específicas e quer relatórios rápidos.

No padrão combinado mais comum, todos os dados chegam primeiro a um data lake e depois são carregados em warehouses e marts para casos de uso específicos. O lake guarda o histórico bruto, completo e barato. O warehouse recebe o subconjunto curado que os analistas consultam todo dia.

Pular o lake funciona quando suas fontes já são estruturadas (bancos de dados, APIs de SaaS) e seus únicos consumidores são dashboards de BI. Pular o warehouse é mais difícil, porque analistas querem SQL rápido e governado, e é exatamente isso que um lakehouse tenta oferecer.

Quanto custam data lakes e data warehouses?

Um lake cobra principalmente por object storage e requisições. Um warehouse cobra por computação (créditos, slot-horas ou node-horas) mais armazenamento comprimido. Os medidores medem coisas diferentes, então os números abaixo podem ser comparados em espírito, mas nunca somados:

O armazenamento em um lake custa hoje quase o mesmo que o armazenamento gerenciado de warehouse por gigabyte, então o preço de armazenamento sozinho raramente decide a arquitetura. A computação é onde as contas divergem: o BigQuery cobra por bytes escaneados, então particionamento e clustering cortam o custo das consultas diretamente, enquanto Snowflake e Redshift cobram por tempo de computação, então o tamanho do warehouse e o tempo de execução puxam a conta.

Preços por crédito do Snowflake para AWS US East (N. Virginia)

O que é um lakehouse e como ele muda a decisão?

Um lakehouse dá recursos de warehouse a arquivos em object storage: transações, imposição de schema e SQL rápido sobre o mesmo armazenamento barato que um lake usa. Ele faz isso com um formato de tabela aberto, uma camada de metadados que registra quais arquivos pertencem a qual versão de uma tabela.

Os dois principais formatos de tabela:

• O Delta Lake estende arquivos Parquet com um log de transações em arquivo. Esse log dá às tabelas transações ACID (atômica, consistente, isolada, durável: uma escrita acontece por completo ou não acontece), validação de schema na escrita e time travel. É o formato padrão no Databricks.
• O Apache Iceberg é um formato de tabela neutro de engine. Spark, Trino, Flink, Presto e Hive podem trabalhar nas mesmas tabelas Iceberg ao mesmo tempo, e mudanças de schema nunca exigem reescrever a tabela.

Um formato de tabela sozinho é uma especificação, e um lakehouse funcionando ainda precisa de catálogo, engine de consulta e pipelines o alimentando. Carregar dados nele é igual a carregar um warehouse: a Erathos, por exemplo, escreve dados de origem direto no Delta Lake no Databricks com particionamento configurável, e os times consultam com Python, SQL ou Spark.

As fronteiras entre lake e warehouse ainda estão claras em 2026?

A fronteira praticamente se dissolveu no nível de plataforma. Produtos de warehouse agora gerenciam tabelas em formato aberto no object storage que você controla, o que antes era a marca registrada do lake.

O Snowflake roda tabelas Iceberg no S3, Google Cloud Storage ou Azure Storage gerenciados por você. Tabelas em um volume externo gerenciado pelo cliente não têm custo de armazenamento do Snowflake. O Snowflake cobra só a computação que as consulta. O BigQuery oferece tabelas Iceberg gerenciadas que armazenam dados em buckets do Cloud Storage do próprio cliente com a mesma experiência das tabelas padrão do BigQuery.

O formato aberto ainda vem com restrições de plataforma. As tabelas Iceberg gerenciadas do BigQuery permitem uma instrução DML (linguagem de manipulação de dados) mutante por tabela por vez, ficam sem views materializadas e sem segurança em nível de linha, e alterar arquivos direto no bucket pode causar perda de dados. O Snowflake documenta seus próprios limites para tabelas que usam um catálogo Iceberg externo. Cada engine ainda tem seus próprios limites sobre o que consegue fazer com esse armazenamento.

Onde o ELT e a movimentação de dados entram?

O ELT carrega os dados no lake ou no warehouse primeiro e transforma lá, nessa ordem: extrair, carregar, transformar. Essa ordem é o que torna possível o padrão de histórico bruto, porque a carga acontece antes de qualquer transformação e a cópia intocada fica disponível para modelagem depois.

A etapa de carga carrega a maior parte das decisões de arquitetura. A Erathos tem mais de 100 conectores e carrega em BigQuery, Databricks, Redshift, ClickHouse, Postgres e S3 Iceberg, então o mesmo desenho de pipeline funciona com destino warehouse, lakehouse ou lake. Cada carga roda como atualização em lote, carga incremental por cursor ou change data capture (CDC), que copia só as linhas que mudaram na origem.

A operação importa tanto quanto o destino. A Erathos agenda syncs de a cada 5 minutos até diário, refaz jobs que falharam e ajusta cursores para reprocessar períodos específicos. Cada execução é registrada com linhas processadas e erros, com alertas no Slack ou por e-mail quando algo quebra. Um lake com ingestão parada ou quebrada em silêncio responde errado, não importa o quão bom seja o formato de tabela.

Resumo rápido

• Data lake: dados brutos no formato nativo, schema-on-read, object storage barato, usuários que trabalham com código.
• Data warehouse: dados limpos e modelados, schema-on-write, SQL rápido, usuários analistas.
• S3 é armazenamento; um lake é S3 mais ingestão, formato de tabela, engine de consulta e governança.
• Lakehouse: tabelas Delta Lake ou Iceberg sobre object storage, com transações e time travel.
• Em 2026, Snowflake e BigQuery rodam tabelas Iceberg em buckets seus.
• Custo: lakes cobram armazenamento e requisições; warehouses cobram computação mais armazenamento comprimido.
• ELT alimenta todos eles: carregue bruto primeiro, transforme no destino.

Pronto para levar seus dados do lake, do warehouse ou dos dois para onde eles precisam estar?

Seja qual for a arquitetura que você escolher, lake, warehouse ou lakehouse, o gargalo raramente é a decisão entre eles. É manter a ingestão funcionando sem parar: schema mudando, rate limit estourando, pipeline quebrando sem avisar. A Erathos carrega dados de mais de 100 fontes direto para BigQuery, Databricks, Redshift, ClickHouse, PostgreSQL ou S3 em formato Iceberg, com sincronização automática e monitoramento de cada carga.

Crie sua conta gratuita na Erathos e comece a carregar seus dados hoje.