Os modelos SQL legados são uma arqueologia dos dados. Tabelas interconectadas sem documentação. Zero versionamento. Zero testes. Quando um número está errado, você rastreia cinco níveis de queries aninhadas para encontrar o bug. Alterar uma coluna quebra em cascata outras dez tabelas. Bem-vindo a 2010.
O dbt em 2026 se impõe como o padrão incontornável para refundar. Porque ele transforma o SQL bruto em código: versionamento, testes, documentação, CI/CD nativo, lineage automático. Refundar com dbt não é uma tarefa pontual, é uma transformação profunda da fabricação de dados.
Por que o legacy SQL está morrendo
Os modelos SQL legados têm uma manutenção custosa — 40% do tempo dos data engineers apenas para manter. O Gartner (2025) relata que 78% das equipes de dados usam dbt ou o consideram seriamente. Por quê? Porque o dbt oferece o que o SQL clássico não consegue.
A modularidade: decompor em camadas claras. Os testes integrados: capturar bugs antes da produção. A documentação viva: não é Word obsoleto. A infraestrutura CI/CD nativa. O DAG (Directed Acyclic Graph) que torna as dependências explícitas.
Um refactoring progressivo leva 6-12 meses, mas reduz em 80% a dívida técnica. Não é um custo, é um investimento que você paga progressivamente.
Três camadas com responsabilidades claras
A arquitetura dbt se baseia em três camadas, cada uma com um papel preciso.
Camada staging (raw): transformação mínima dos dados brutos. Renomeação das colunas, tipagem, deduplicação, normalização dos formatos. Sem lógica de negócio aqui. Apenas limpeza de superfície.
Camada intermediate: a lógica complexa vive aqui. Cálculos, joins, agregações. As tabelas intermediárias são reutilizáveis por vários marts finais. É onde os dados começam a falar a linguagem do negócio.
Camada marts: tabelas de negócio prontas para BI. Suficientemente estruturadas para análise. É o que os usuários finalmente consomem.
Essa separação reduz em 60% o custo de manutenção porque uma lógica complexa é definida apenas uma vez em intermediate, reutilizada em todo lugar. O erro clássico: colocar toda a lógica em marts. Resultado: duplicação de código, pesadelo de manutenção.
Testes = confiança em produção
Os testes em dbt são de primeira classe. Not_null, unique, accepted_values, relationships. E testes custom SQL. Cada coluna crítica deve ter no mínimo um teste.
As tabelas intermediárias são testadas para detectar anomalias antes da propagação em marts. O dbt Labs relata que modelos com testes reduzem em 85% os bugs em produção.
Os testes são executados na CI do dbt Cloud: cada merge request dispara os testes antes da produção. É a barreira de segurança contra transformações ruins. Sem testes, é código não confiável. Com testes, é engenharia.
Documentação viva, não papel morto
O dbt gera automaticamente a documentação via arquivos YAML. Cada coluna, cada tabela pode ter descrição detalhada com regras de cálculo e casos de uso. O lineage DAG mostra visualmente como os dados fluem da fonte até o BI.
Uma mudança em staging mostra imediatamente o impacto nos marts dependentes. É a rastreabilidade que reduz enormemente as investigações em produção. A documentação dbt é viva — ela é atualizada quando o código muda. É a documentation-as-code aplicada aos dados.
Modularidade via Jinja2 e macros
O dbt permite fatorar via Jinja2 (templates) e macros. Em vez de copiar e colar a mesma lógica dez vezes, você cria uma macro reutilizável. Transformar datas? Normalizar nomes de colunas? Aplicar uma lógica de negócio complexa? Uma macro uma vez, usada em todo lugar.
Os testes custom genéricos: definir uma regra de negócio uma vez, aplicá-la a 50 colunas sem duplicação. dbt Packages (bibliotecas open-source de macros) aceleram o desenvolvimento. dbt-utils, dbt-expectations. A modularidade reduz em 40% o tempo de desenvolvimento de novas tabelas.
CI/CD nativo para produção confiável
O dbt Cloud oferece CI/CD nativo: cada pull request dispara testes em um schema efêmero, validando as mudanças antes da produção. O merge automático em produção só acontece após o sucesso dos testes. O histórico de cada modificação é registrado.
A migração a partir do legacy é feita progressivamente. Refundar 5-10% dos modelos por sprint. Depois os outros. Nunca um big-bang que paralisaria. Os primeiros meses formam as equipes na filosofia dbt, no Jinja2, nos testes. Depois a aceleração se inicia. Após 6-12 meses, a equipe dobra sua velocidade graças à reusabilidade e à automação.
A verdadeira mudança: cultura
Refundar com dbt não é um projeto de TI, é uma transformação da cultura de dados. Código versionado, testes, documentação viva, CI/CD nativo. Uma equipe de dados adotando dbt ganha 40% em produtividade e reduz a dívida técnica em 80%.
É o investimento mais rentável para uma equipe de dados que quer passar do ad hoc à produção robusta. E é industrial — é produção de verdade.
