ETL vs ELT: qual abordagem escolher

A pergunta não é ETL ou ELT, é onde a transformação acontece#

Quase toda discussão sobre ETL vs ELT começa no lugar errado. O time acha que precisa escolher uma ferramenta, quando na verdade precisa decidir algo mais simples e mais consequente: em que ponto do caminho o dado bruto vira dado tratado. No ETL, a transformação acontece antes da carga, em uma engine intermediária, e só o resultado limpo chega ao destino. No ELT, o dado bruto é carregado primeiro e transformado depois, dentro do próprio destino, aproveitando a computação do warehouse ou do lakehouse. Toda a diferença de custo, governança e reprocessamento sai dessa única troca de ordem.

Este artigo trata a decisão como ela é na prática, sem torcer para nenhum lado por moda. Comparamos as duas abordagens ponto a ponto, mostramos por que o Microsoft Fabric empurra o padrão para o ELT, apontamos onde o ETL clássico ainda é a resposta certa e detalhamos o impacto real em custo, governança e reprocessamento.

ETL vs ELT: a diferença está na ordem, não na sigla#

As letras são as mesmas, só mudam de lugar: Extract, Transform, Load contra Extract, Load, Transform. Parece detalhe de acrônimo, mas a posição do T muda toda a arquitetura.

No ETL, você extrai o dado da origem, transforma em um servidor dedicado de integração e carrega no destino já limpo, agregado e no formato final. O destino recebe apenas o que passou pelo filtro. Era o padrão natural quando armazenamento era caro e a capacidade do banco de destino era limitada: fazia sentido não jogar dado bruto lá dentro.

No ELT, você extrai, carrega o dado bruto no destino como ele veio da origem e só então transforma, usando o processamento da própria plataforma de destino. O histórico bruto e as camadas tratadas convivem no mesmo lugar. Essa inversão só ficou viável porque armazenamento barato e computação elástica deixaram de ser luxo, e é exatamente o cenário das plataformas de dados na nuvem hoje.

Critério	ETL	ELT
Ordem das operações	Transforma antes de carregar	Carrega bruto e transforma no destino
Onde a transformação roda	Engine intermediária dedicada	Motor do warehouse ou lakehouse
O que chega ao destino	Só o dado já tratado	Dado bruto mais as camadas tratadas
Histórico do dado cru	Geralmente descartado no meio	Preservado no destino
Pré-requisito de infraestrutura	Servidor de integração dimensionado	Armazenamento barato e computação elástica
Reprocessamento de regra antiga	Exige reextrair da origem	Refaz a transformação sobre o bruto já carregado

ETL: transformar antes de carregar ainda tem lugar#

Enterrar o ETL seria erro de consultor apressado. Ele continua sendo a escolha certa em cenários específicos, e vale nomear quais.

O primeiro é o requisito rígido de qualidade na entrada. Quando o destino não pode receber dado inconsistente, transformar antes funciona como um portão: só passa o que já foi validado. Sistemas regulados e integrações que alimentam processos financeiros críticos preferem esse controle na porta.

O segundo é o dado sensível que não deveria sequer ser armazenado bruto. Se a origem traz CPF, dado de saúde ou informação de cartão que precisa ser mascarada antes de tocar o repositório analítico, faz sentido transformar no meio do caminho e nunca gravar o valor original no destino. É uma decisão de governança, não de performance.

O terceiro é a integração legada. Muita empresa brasileira roda pipelines de ETL maduros, ligados a sistemas on-premises. Reescrever tudo para ELT só porque é a tendência é trocar risco conhecido por risco novo sem ganho proporcional. Migração de padrão se justifica por necessidade, não por estética.

A fraqueza do ETL aparece quando a regra muda. Como o dado bruto normalmente não fica guardado, corrigir uma transformação de dois anos atrás costuma exigir reextrair da origem, e a origem nem sempre ainda tem aquele histórico.

ELT: carregar bruto e transformar no destino virou o padrão#

O ELT ganhou o mercado por um motivo econômico antes de qualquer motivo técnico: guardar dado bruto ficou barato. Quando o armazenamento custa pouco e a computação escala sob demanda, deixou de fazer sentido descartar o dado cru para economizar espaço. Guardar tudo e transformar depois virou a opção mais flexível e, muitas vezes, a mais barata.

A vantagem central do ELT é que o dado bruto permanece disponível no destino. Quando a regra muda, quando aparece um erro na lógica de agregação ou quando o negócio pede um recorte que ninguém previu, você refaz a transformação sobre o dado que já está lá, sem depender da origem. Reprocessar deixa de ser um projeto e vira uma execução de pipeline.

A segunda vantagem é usar a computação do destino. Warehouses e lakehouses modernos foram construídos para processar transformação em escala, com computação elástica que sobe quando o job pesado roda e desce quando termina. Em vez de manter um servidor de integração dimensionado para o pico o ano inteiro, você paga o processamento na hora em que ele acontece.

O ELT também tem seu preço, e ele é honesto: guardar dado bruto significa guardar dado sensível bruto. Sem governança, o repositório vira um acúmulo de informação pessoal que ninguém mapeou. Não é defeito do ELT, é a conta que vem junto com a flexibilidade e que precisa ser tratada desde o primeiro dia.

Por que o Lakehouse e o Warehouse do Fabric favorecem o ELT#

O Microsoft Fabric foi desenhado em cima das duas premissas que tornam o ELT viável: armazenamento barato e computação elástica. Tanto o item Lakehouse quanto o item Warehouse do Fabric guardam dados no OneLake em formato aberto e processam transformação com a própria capacidade da plataforma. Isso não é acidente de produto, é a direção para onde o ecossistema apontou.

Na prática, o padrão natural dentro do Fabric é carregar o dado bruto no Lakehouse, transformar por camadas com notebooks, SQL ou o Dataflow Gen2 e servir o resultado ao Power BI. O dado não precisa sair para um servidor externo: o motor que armazena é o mesmo que processa, e é isso que caracteriza o ELT.

Isso não significa que o Fabric proíba o ETL. Você pode transformar dado antes de carregar usando as próprias ferramentas dele, e para qualidade na entrada ou mascaramento de dado sensível isso continua fazendo sentido. O ponto é que a plataforma torna o ELT o caminho de menor atrito, e lutar contra ele sem motivo forte custa mais do que vale. Se você ainda avalia a plataforma, vale ler nossa análise sobre o que é o Microsoft Fabric e se ele vale a pena antes de decidir o padrão de integração.

A arquitetura medalhão é ELT com disciplina#

Quando alguém descreve a arquitetura medalhão, com as camadas bronze, silver e gold, está descrevendo ELT organizado. Não é uma terceira abordagem entre ETL e ELT, é a forma madura de fazer ELT sem virar bagunça.

A lógica é direta. A camada bronze recebe o dado bruto exatamente como veio da origem, sem transformação: é o Load do ELT. A silver limpa, valida, remove duplicidade e padroniza tipos. A gold agrega e modela o dado no formato que o negócio consome, tipicamente as tabelas fato e dimensão que alimentam o Power BI. As duas últimas camadas são o Transform, e ele acontece depois da carga, dentro do destino.

O valor da separação em camadas é que cada transformação fica rastreável e refazível. Se a regra da gold muda, você reprocessa da silver ou da bronze sem tocar na origem. É o benefício de reprocessamento do ELT transformado em processo, não em improviso.

Camada	O que guarda	Papel no ELT
Bronze	Dado bruto, como veio da origem	O Load: carrega sem transformar
Silver	Dado limpo, validado e padronizado	Primeira parte do Transform
Gold	Dado agregado e modelado para consumo	Transform final, pronto para o BI

Custo, governança e reprocessamento: onde a decisão dói de verdade#

A escolha entre ETL e ELT não é abstrata. Ela aparece na fatura, na auditoria de LGPD e no dia em que alguém pede para refazer uma carga. Vale olhar os três de frente.

Custo. No ETL, o custo se concentra no servidor de integração, dimensionado para o pico mesmo que fique ocioso boa parte do tempo. No ELT, ele se divide entre armazenar dado bruto, que é barato, e processar transformação com computação elástica, que você paga quando roda. O ELT tende a sair mais barato em volume variável, mas exige disciplina: transformação mal escrita rodando sobre dado bruto em escala vira conta alta rápido.

Governança. O ETL tem uma vantagem natural aqui: se você transforma antes de carregar, pode nunca gravar o dado sensível bruto no destino. O ELT carrega tudo, inclusive o que é sensível, e concentra risco na camada bronze. Nenhuma das duas abordagens dispensa governança, mas o ELT exige que ela venha desde o início: mapear onde o dado pessoal entra, quem acessa cada camada e como um pedido de exclusão de titular se propaga por bronze, silver e gold. Esse trabalho é parte do projeto de engenharia de dados, não um extra.

Reprocessamento. É onde o ELT abre a maior distância. Como ele preserva o dado bruto no destino, refazer uma transformação é executar de novo o pipeline sobre o que já está lá. No ETL clássico, sem o bruto guardado, reprocessar depende de a origem ainda ter o histórico, o que nem sempre é verdade. Quem já corrigiu uma regra de faturamento de meses atrás sabe o peso dessa diferença.

Dimensão	ETL	ELT
Onde pesa o custo	Servidor de integração dimensionado para o pico	Armazenamento barato mais processamento elástico
Dado sensível bruto	Pode nunca chegar ao destino	Chega ao destino, concentra risco na bronze
Reprocessar regra antiga	Depende da origem ainda ter o histórico	Refaz sobre o bruto já carregado
Esforço de governança	Controle na entrada	Governança por camada desde o início
Melhor cenário	Qualidade rígida na entrada, dado sensível, legado	Volume variável, flexibilidade, nuvem moderna

Quando cada abordagem faz sentido: uma decisão honesta#

A resposta honesta é que a maioria dos projetos novos na nuvem começa em ELT, e isso é correto. Se você monta uma plataforma de dados hoje sobre Fabric, Databricks ou qualquer stack moderno, o ELT com arquitetura medalhão é o caminho de menor atrito e maior flexibilidade. Carregar bruto e transformar no destino é o padrão pelo qual essas plataformas foram construídas.

O ETL segue certo quando existe motivo concreto: qualidade inegociável na entrada, dado sensível que não pode ser gravado bruto, ou integração legada madura. Escolha ETL por necessidade, nunca por hábito. E não é raro o cenário híbrido: ETL para as poucas origens que exigem mascaramento na porta e ELT para todo o resto.

O erro que mais vemos não é escolher a abordagem errada, é escolher sem critério e pagar caro para desfazer. Definir o padrão de integração antes de mover o primeiro dado economiza um retrabalho caro. Se o consumo final é Power BI, vale alinhar a decisão com como o modelo será servido, tema que tratamos no serviço de Power BI.

Perguntas frequentes#

ETL está obsoleto? Não. Mudou de proporção. As arquiteturas modernas favorecem o ELT porque o custo de guardar dado bruto caiu e a flexibilidade de reprocessar dentro da plataforma compensa. Mas requisitos rígidos de qualidade na entrada, dado sensível que não deve ser gravado bruto e integrações legadas maduras ainda justificam o ETL clássico.

O ELT é sempre mais barato que o ETL? Nem sempre. O armazenamento de dado bruto é barato, mas a transformação rodando em escala consome processamento que precisa ser controlado. Sem disciplina de pipeline, o ELT pode sair caro. A economia é real em volume variável e some quando ninguém governa o custo de processamento.

A arquitetura medalhão é ETL ou ELT? É ELT. A camada bronze carrega o dado bruto sem transformar, e as camadas silver e gold fazem a transformação depois, dentro do destino. É a forma organizada de fazer ELT, com cada etapa rastreável e refazível a partir do dado cru preservado na bronze.

Preciso escolher só uma abordagem para a empresa inteira? Não. É comum e saudável usar ETL para as poucas origens que exigem mascaramento ou validação na entrada e ELT para todo o resto. A abordagem se escolhe por origem e por requisito, não como dogma único para toda a plataforma.

O Microsoft Fabric obriga a usar ELT? Não obriga, mas favorece. O Lakehouse e o Warehouse do Fabric guardam dados no OneLake e processam transformação com a computação da própria plataforma, o que torna o ELT o caminho natural. Você ainda pode transformar antes de carregar quando houver motivo, como dado sensível ou qualidade rígida na entrada.

Por que o reprocessamento é mais fácil no ELT? Porque o dado bruto fica guardado no destino. Quando uma regra muda ou um erro aparece, você refaz a transformação sobre o dado que já está lá, sem depender de a origem ainda ter o histórico. No ETL sem o bruto preservado, reprocessar exige reextrair da origem, o que nem sempre é possível.

A decisão certa é a que seu cenário sustenta#

ETL e ELT não competem como produtos de prateleira. São respostas a requisitos diferentes de custo, governança e reprocessamento, e a escolha certa depende do seu dado, do seu time e das suas restrições reais. Para projetos novos na nuvem, o ELT com arquitetura medalhão é o ponto de partida honesto. Para qualidade rígida na entrada ou dado sensível, o ETL segue vivo e correto. O erro caro é decidir sem critério.

Se você quer definir o padrão de integração da sua plataforma de dados com apoio de quem já estruturou os dois cenários em produção, fale com a gente.