# Ferramenta de ETL ou pipeline próprio: como escolher pelas fontes > Ferramenta de ETL pronta ou pipeline próprio? Veja como decidir pelas suas fontes de dado, quando o conector pronto vence e por que o modelo misto é tão comum. Fonte: https://pervian.tech/blog/ferramenta-de-etl-ou-pipeline-proprio · Pervian Tech · publicado em 2026-10-01 A empresa decidiu que precisa de um painel confiável, ou de um data warehouse, e alguém da equipe técnica levanta a questão inevitável: como o dado vai sair do ERP, do CRM, do e-commerce e das planilhas e chegar até lá? Uma parte da equipe sugere contratar uma ferramenta de ETL com conectores prontos. Outra parte prefere escrever o pipeline em código, sob controle da casa. As duas posições são razoáveis, e a discussão costuma ficar presa em preferências. Este texto propõe um critério mais objetivo, baseado nas fontes que a sua empresa realmente tem. Se o conceito ainda é novo, vale ler antes [ETL: o que é e como o dado chega ao seu dashboard](https://pervian.tech/blog/etl-e-pipeline-de-dados). **Resposta curta:** decida pela natureza das fontes. Se a maioria delas é sistema SaaS conhecido, com esquema estável e conector maduro no mercado, uma ferramenta de ETL resolve rápido e libera a equipe para cuidar das regras de negócio. Se as fontes principais são ERP customizado, banco legado, arquivos enviados por parceiros ou regras que só existem na empresa, o pipeline próprio compensa. O critério prático é contar quantas fontes têm conector maduro. ## Extrair, transformar e carregar: onde está o trabalho de verdade ETL quer dizer extrair, transformar e carregar. Na conversa sobre ferramentas, as três etapas costumam ser tratadas como se pesassem a mesma coisa. Não pesam. **Extrair** é buscar o dado na origem: ler a API de um sistema, consultar um banco, baixar um arquivo. Para sistemas populares, esse trabalho é repetitivo e muito parecido de empresa para empresa. É exatamente o que uma ferramenta pronta faz bem. **Carregar** é gravar o dado no destino, normalmente um data warehouse na nuvem. Também é uma etapa bastante padronizada. **Transformar** é onde mora o negócio: unificar o cadastro de cliente que aparece de três jeitos, decidir se devolução entra no faturamento, converter unidades, aplicar a regra de rateio que o controller definiu. Nenhuma ferramenta conhece essas regras de antemão, porque elas são da sua empresa. Muitas equipes hoje fazem ELT: extraem e carregam o dado bruto primeiro e transformam dentro do próprio data warehouse. A ordem muda, mas a conclusão é a mesma. A parte genérica (extrair e carregar) pode ser comprada. A parte específica (transformar) sempre vai exigir trabalho de quem conhece o negócio. Por isso a pergunta "ferramenta ou código?" é, na verdade, sobre a extração. É ali que a natureza das fontes faz toda a diferença. ## Conectores prontos: Fivetran, Airbyte e similares Fivetran, Airbyte, Stitch e outras ferramentas do mesmo tipo oferecem uma biblioteca de conectores para sistemas e bancos de dados conhecidos. Em geral, você escolhe a fonte e o destino, e a ferramenta cuida da extração, da carga e do agendamento. Há opções comercializadas como serviço em nuvem e opções de código aberto que a própria empresa pode hospedar. Várias delas também permitem escrever conectores personalizados dentro da própria plataforma, o que ajuda quando falta só uma ou duas fontes, mas transfere para a sua equipe a manutenção desses conectores específicos. O que esse tipo de ferramenta faz muito bem: - **Velocidade para começar.** Para uma fonte com conector pronto, o dado pode estar no warehouse em pouco tempo, sem escrever código de extração. - **Manutenção terceirizada do conector.** Quando o fornecedor do sistema de origem muda a API, quem atualiza o conector é o fornecedor da ferramenta, não a sua equipe. - **Recursos operacionais já resolvidos.** Agendamento, novas tentativas em caso de falha, alertas e registro de execuções costumam vir prontos. Os limites aparecem quando: - **O conector não existe ou é imaturo.** Conectores variam muito em qualidade. Alguns são amplamente usados e bem mantidos; outros são recentes, cobrem só parte das tabelas ou foram construídos pela comunidade. - **O sistema de origem foi customizado.** Um conector feito para a versão padrão de um ERP pode não enxergar os campos e as tabelas que a sua empresa acrescentou. - **O modelo de cobrança cresce com o volume.** Muitas ferramentas cobram de acordo com a quantidade de dados processados ou de linhas sincronizadas. Vale simular o custo com o volume real antes de assinar e de novo quando a empresa crescer. - **Há exigências de onde o dado pode trafegar.** Dados pessoais e informações sensíveis pedem atenção a onde a ferramenta processa e armazena o dado, inclusive por conta da LGPD. Recursos, conectores disponíveis, preços e condições mudam com frequência. Confirme sempre com o fornecedor o que vale hoje para as suas fontes específicas, de preferência com um teste usando os seus próprios sistemas. ## Pipeline próprio: código, agendamento e monitoramento Pipeline próprio não é um script rodando no computador de alguém. Feito direito, ele tem pelo menos quatro partes: 1. **Código de extração e carga**, versionado, revisado e com testes, escrito em uma linguagem que a equipe domina. 2. **Orquestração**, ou seja, uma ferramenta de agendamento (Airflow, Dagster e Prefect são exemplos conhecidos de código aberto) que sabe a ordem das tarefas, refaz o que falhou e não roda a etapa seguinte sobre dado incompleto. 3. **Monitoramento e alertas**: saber que a carga da madrugada falhou antes da reunião das nove, e não depois. 4. **Documentação**: de onde vem cada tabela, com que frequência é atualizada e quem responde por ela. A vantagem é o controle. O pipeline lê exatamente o que a fonte oferece, do jeito que ela oferece, inclusive quando isso significa um arquivo em formato próprio ou uma consulta cuidadosa em um banco antigo. O custo de operação também tende a ser mais previsível, porque depende da infraestrutura contratada e das horas de manutenção, não do volume de linhas sincronizadas. Só não confunda previsível com baixo: o tempo de quem desenvolve e mantém o pipeline é o maior custo, e precisa entrar na conta. A desvantagem é igualmente clara: toda a manutenção é sua. Quando a API da fonte muda, quando o servidor de arquivos troca de endereço, quando alguém altera uma coluna no banco legado, é a sua equipe (ou o seu fornecedor) que precisa corrigir. Pipeline próprio sem monitoramento é a forma mais comum de dado desatualizado que ninguém percebe. ## Fontes difíceis: ERP customizado, banco legado e arquivos É aqui que a decisão costuma se resolver sozinha. Em muitas empresas médias brasileiras, o mapa de fontes tem dois grupos bem diferentes. **Fontes fáceis:** plataforma de e-commerce conhecida, CRM de mercado, ferramenta de marketing, gateway de pagamento, planilha em nuvem. São sistemas usados por muitas empresas, com API documentada e, muitas vezes, conector pronto. **Fontes difíceis:** o ERP que foi customizado ao longo de anos, o sistema de produção desenvolvido internamente, o banco de dados de um software que não tem mais suporte, a planilha que o parceiro envia toda segunda-feira com colunas que mudam de nome, o arquivo de retorno que só um sistema específico gera. Para as fontes difíceis, raramente existe conector maduro. E, quando existe, ele não conhece as customizações. O trabalho de extração passa a envolver decisões que só quem olha o caso consegue tomar: - **Ler direto do banco ou por réplica?** Consultas pesadas no banco de produção do ERP podem deixar o sistema lento para quem está faturando. - **Carga completa ou incremental?** Sistemas antigos nem sempre têm uma coluna confiável de "última alteração", o que complica buscar só o que mudou. As saídas vão de recarregar tabelas pequenas por inteiro a ler o log de transações do banco (a chamada captura de mudanças, ou CDC), que exige acesso e configuração no servidor. - **Como lidar com arquivos de terceiros?** Validar o formato na chegada, rejeitar o que vier quebrado e avisar o responsável, em vez de carregar lixo silenciosamente. - **Como não depender de tela?** Quando o sistema não oferece nem banco acessível nem exportação, às vezes o caminho é uma camada intermediária. Detalhamos essas opções em [como integrar um sistema legado que não tem API](https://pervian.tech/blog/integrar-sistema-legado-sem-api). Se as suas fontes mais importantes estão nesse segundo grupo, o pipeline próprio deixa de ser preferência e passa a ser necessidade, ao menos para essas fontes. ## Transformação e regras de negócio: dbt e a camada de modelagem Independentemente de como o dado chega ao warehouse, a transformação precisa de um lar. A pior opção é espalhar regra de negócio em fórmulas de relatório, consultas soltas e planilhas de apoio. Ninguém audita, ninguém testa e cada relatório acaba com sua própria versão do número. Ferramentas como o dbt popularizaram uma abordagem que vale para qualquer cenário: escrever as transformações em SQL, versionadas como código, com testes automáticos e documentação gerada a partir do próprio projeto. A camada de modelagem costuma ser organizada em etapas: - **Dado bruto**, exatamente como veio da fonte, para que seja possível reprocessar. - **Dado tratado**, com nomes padronizados, tipos corrigidos e duplicidades resolvidas. - **Dado de negócio**, com as métricas oficiais calculadas uma única vez: faturamento líquido, margem, prazo de entrega, o que for relevante. Essa camada é sempre específica da empresa, use você uma ferramenta de ETL ou pipeline próprio para extrair. É também onde se resolve boa parte das divergências descritas em [qualidade de dados: por que seu relatório não bate](https://pervian.tech/blog/qualidade-de-dados-relatorios-nao-batem). Testes simples, como "nenhum pedido sem cliente" ou "o total do dia não pode ser zero em dia útil", pegam problemas antes de eles chegarem à diretoria. ## Tabela comparativa: ferramenta de ETL x pipeline próprio | Critério | Ferramenta de ETL com conectores | Pipeline próprio | |---|---|---| | Fontes SaaS conhecidas | Costuma resolver rápido | Exige escrever e manter código para cada uma | | ERP customizado e banco legado | Conector pode não existir ou não enxergar customizações | Lê exatamente o que a fonte oferece | | Arquivos de parceiros | Suporte genérico, validação limitada ao que a ferramenta oferece | Validação e regras de rejeição sob medida | | Tempo até o primeiro dado | Curto, quando há conector | Maior, pois exige desenvolvimento | | Manutenção quando a fonte muda | Do fornecedor, nos conectores oficiais; nos comunitários ou personalizados, pode ser sua | Responsabilidade da sua equipe ou fornecedor | | Custo ao crescer | Depende do modelo de cobrança, muitas vezes ligado a volume | Mais previsível, ligado à infraestrutura e à manutenção | | Monitoramento e novas tentativas | Normalmente incluídos | Precisam ser construídos e configurados | | Controle sobre onde o dado trafega | Depende do fornecedor; versões auto-hospedadas dão mais controle | Definido por você, na infraestrutura que a empresa escolher | | Transformação e regras de negócio | Feita em camada separada (por exemplo, dbt) | Feita em camada separada (por exemplo, dbt) | Repare na última linha: ela é igual nos dois lados. A diferença entre as abordagens está na extração e na operação, não na modelagem. ## Quando escolher cada um (e o modelo misto) ### Sinais de que a ferramenta de ETL é a melhor escolha - A maioria das fontes é sistema SaaS de mercado com conector amplamente usado. - Os sistemas de origem são usados de forma padrão, sem grandes customizações. - A equipe técnica é pequena e precisa gastar o tempo na modelagem e nos indicadores, não em código de extração. - O volume de dados é moderado e a simulação de custo com o volume real faz sentido para o orçamento. - Não há restrição contratual ou regulatória que impeça o dado de passar pela infraestrutura do fornecedor. Nesse cenário, escrever extração própria para sistemas com conector maduro é reinventar o que outros já mantêm. ### Sinais de que o pipeline próprio compensa - As fontes que mais importam para a gestão são ERP customizado, sistema interno ou banco legado. - Parte relevante dos dados chega em arquivos de parceiros, fornecedores ou bancos, com formatos próprios. - A extração precisa de cuidados específicos para não pesar no sistema de produção. - O volume é alto e o modelo de cobrança por volume ficaria desproporcional. - Há exigências rígidas sobre onde o dado pode ser processado e armazenado. ### O modelo misto, que costuma ser a resposta Em boa parte das empresas médias, o mapa de fontes tem os dois grupos. A arquitetura que costuma funcionar melhor é mista: 1. **Ferramenta de ETL para as fontes fáceis**, como e-commerce, CRM e ferramentas de marketing. 2. **Pipeline próprio para as fontes difíceis**, como ERP customizado, banco legado e arquivos. 3. **Um único destino**, o data warehouse, recebendo as duas cargas. 4. **Uma única camada de modelagem**, com as regras de negócio escritas uma vez e testadas. 5. **Um único monitoramento**, que mostra o estado de todas as cargas, venham de onde vierem. O ponto 5 é o que faz o modelo misto dar certo. Para entender como organizar o destino dessas cargas, veja [data warehouse para empresa média: por onde começar](https://pervian.tech/blog/data-warehouse-para-empresas-medias). ### Um exercício para fazer antes de decidir Liste todas as fontes de dado que alimentam os indicadores da diretoria. Para cada uma, anote: é sistema de mercado ou interno? Foi customizado? Existe conector maduro e amplamente usado para ela? Qual a importância dessa fonte para os números principais? Se a maior parte das fontes importantes tem conector maduro, comece pela ferramenta. Se a maior parte não tem, o pipeline próprio é o centro e a ferramenta pode entrar pontualmente. ## Perguntas frequentes ### Qual a diferença entre ETL e ELT? ETL transforma o dado antes de carregá-lo no destino, enquanto ELT carrega o dado bruto primeiro no data warehouse e faz a transformação lá dentro. A ordem muda, mas a decisão entre ferramenta de ETL e pipeline próprio continua a mesma: extrair e carregar podem ser comprados, e as regras de negócio sempre exigem trabalho específico da empresa. ### Dá para usar ferramenta de ETL com ERP customizado? Depende do conector. Um conector feito para a versão padrão do ERP pode não enxergar os campos e as tabelas que a empresa acrescentou ao longo dos anos. Quando o ERP customizado é a fonte mais importante dos indicadores, o mais comum é extraí-lo com pipeline próprio e usar a ferramenta de ETL apenas para os sistemas SaaS de mercado. ### Pipeline próprio sai mais barato que ferramenta de ETL? Nem sempre. O pipeline próprio tem custo de infraestrutura mais previsível, porque não depende do volume de linhas sincronizadas, mas o maior custo é o tempo de quem desenvolve e mantém o código, a orquestração e o monitoramento. A ferramenta de ETL tende a sair na frente quando as fontes têm conector maduro e o volume de dados é moderado. ### Precisa de monitoramento em um pipeline de dados? Sim. Um pipeline de dados sem monitoramento é a forma mais comum de painel desatualizado que ninguém percebe. O mínimo é ter alerta quando uma carga falha, registro de cada execução e testes que conferem o resultado, como o total do dia não ser zero em dia útil, antes que o número chegue à reunião da diretoria. ## Como a Pervian Tech ajuda a decidir e a levar o dado até o painel Começamos com um diagnóstico inicial gratuito: mapeamos as fontes de dado, verificamos quais têm conector maduro, avaliamos as customizações do ERP e os arquivos que chegam de fora, e entendemos quais indicadores a diretoria precisa. A recomendação sai desse mapa, não de preferência por ferramenta. Quando uma ferramenta de ETL de mercado atende as suas fontes, recomendamos esse caminho e ajudamos a configurá-lo bem. Quando as fontes são difíceis, construímos o pipeline próprio com orquestração, monitoramento e documentação, e montamos a camada de modelagem com as regras de negócio testadas. Esse desenho faz parte do nosso trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software), e o caminho até o painel final é o que entregamos em [dashboards e BI sob medida](https://pervian.tech/solucoes/dashboards-e-bi-sob-medida). Outros textos sobre o tema estão na categoria [dados e BI](https://pervian.tech/blog/categoria/dados-e-bi). O investimento é definido sob consulta, depois de entender o número e a natureza das fontes. Se o dado da sua empresa ainda chega ao painel por exportações manuais e planilhas de apoio, [conte para nós como é hoje](https://pervian.tech/#contato).