Engenharia de analytics para times pequenos: os seis estágios que quase ninguém respeita

Em abril de 2026, o dbt-core foi baixado do PyPI 97,5 milhões de vezes em um único mês. Existem cerca de 90.000 projetos dbt rodando em produção pelo mundo. Em algum lugar dentro desse número está um time de sete pessoas cuja stack de dados inteira é uma planilha do Google, três Dashboards do Looker Studio e uma réplica de Postgres que um engenheiro consulta com SQL na unha quando alguém faz uma pergunta. Esse time está bem. Talvez ainda não precise de dbt. Provavelmente vai precisar daqui a seis meses, e a pior coisa que pode fazer nesse meio-tempo é pular direto para uma divisão de marts em três camadas com semantic layer.

Esse texto é para esse time, e para a meia dúzia de variações dele que vejo todo trimestre. Cinco a cinquenta pessoas, sem engenheiro de dados dedicado, um fundador ou líder de operações que herdou "analytics" porque era quem se virava melhor com planilha. Tem gente do Brasil e dos EUA/Europa no meio. Já pagam por pelo menos uma ferramenta de BI. Já brigam sobre qual número de receita é o certo.

O que vem a seguir é um modelo de maturidade em seis estágios. Cada estágio nomeia o sinal operacional que indica a hora de avançar, o que é estrutural no estágio e o que é prematuro, e o único modo de falha que mais derruba times ali. O modo de falha que domina em todos os estágios é o mesmo: pular etapas. Queimar meses em uma semantic layer antes de o staging estar estável. Construir três subdiretórios de mart quando você tem quatro modelos de mart. A própria documentação do dbt diz isso sem rodeio: "se você tem menos de 10 modelos de mart e não está tendo problema para desenvolver e usá-los, pode ignorar subdiretórios completamente". A maioria dos times passa batido por essa linha logo no primeiro dia.

O trabalho, no fim das contas, é quase todo encanamento. O modelo de maturidade abaixo é um argumento sobre qual encanamento vale a pena instalar em qual estágio, e qual é prematuro.

Estágio 1: planilhas, e está tudo bem

A maioria das empresas pequenas começa a vida analítica em uma planilha, e a maioria deveria ficar nela por mais tempo do que imagina. Uma planilha é um banco de dados, um motor de query, uma biblioteca de gráficos e uma ferramenta de apresentação no mesmo arquivo. Para um time de sete tentando entender se um teste de preço funcionou ou qual campanha está convertendo, a planilha é mesmo a resposta certa. Não tem infraestrutura para manter, nem migração de schema, nem SQL para escrever, e cada rodada de ajuste leva dois segundos.

Não tenho um número defensável de quantas empresas pequenas vivem em planilhas. As pesquisas publicadas só ouvem quem já se considera profissional de dados, o que enviesa a resposta. Mas toda empresa com quem trabalhei abaixo de trinta funcionários faz pelo menos 60% do reporting no Sheets ou no Excel, e não é aí que mora o problema. O problema é o que eles fazem depois.

O sinal de que é hora de avançar. A mesma planilha foi editada por quatro pessoas esse mês e duas delas passaram a duplicar antes de mexer. Ou: um número em que você confiou no trimestre passado agora está errado, e ninguém consegue refazer o caminho até entender o porquê. Ou: você precisa explicar para um recém-contratado qual aba é a visão "de verdade" do pipeline. Quando a planilha começa a se dividir em cópias em vez de ser compartilhada, você já passou do estágio 1.

O que é estrutural. Convenções de nomenclatura. Um único dono por arquivo. Um ritmo semanal em que os números são atualizados e alguém de fato olha para eles. Nada disso tem glamour, e pular essa parte é o que cria o caos que depois jogam na conta do warehouse, como se o problema fosse ele.

O que é prematuro. Um warehouse. Uma ferramenta de BI. dbt. Qualquer um cochichando sobre data lake.

Modo de falha. Tratar o estágio de planilha como uma falha moral e pular direto para uma conta no Snowflake porque um amigo numa Series B recomendou. A fatura do primeiro mês é pequena, a do sexto não é, e o time continua fazendo o reporting na mesma planilha porque ninguém nunca chegou a alimentar o warehouse.

Estágio 2: métricas em código de produção

O estágio 2 é a primeira vez em que uma métrica deixa de ser uma referência de célula e passa a ser uma query. Em geral isso quer dizer que alguém (muitas vezes um engenheiro de backend cansado de tanto responder pergunta) escreveu uma view SQL no banco de produção, ou um script Python pequeno que bate na API, calcula o número e grava em algum lugar. O número agora é reproduzível. Duas pessoas que rodam a query chegam à mesma resposta. É essa a promessa inteira do estágio 2.

O formato varia. Alguns times colocam o SQL num metrics.sql dentro do repo da aplicação e um cron roda toda noite. Outros batem numa réplica de leitura pelo Metabase. Outros usam Hex ou um notebook. O que todos têm em comum é que a definição da métrica vive em código que alguém pode revisar, não numa planilha que qualquer um reescreve sem te avisar.

O sinal de que é hora de avançar. Você tem mais de dez dessas queries. Duas delas dão números diferentes para a mesma métrica. Ou você começou a repetir o mesmo JOIN em três queries porque três relatórios diferentes precisam da mesma tabela de cliente.

O que é estrutural. Controle de versão no SQL. Uma única definição canônica para as três ou quatro métricas que a empresa de fato discute (receita, MRR, usuários ativos, ou sejam lá quais forem as suas). Um agendamento, mesmo que seja um cron preso com durex.

O que é prematuro. dbt. Uma camada de modelagem. Testes. Você ainda não tem modelos suficientes para os testes valerem o esforço.

Modo de falha. Deixar cada time escrever a própria versão da mesma query. O time de CRM monta um relatório de "deals fechados esse mês", o financeiro monta outro a partir do Stripe, o time de growth pluga o Looker direto numa réplica transacional com SQL próprio, e aí você tem três definições de receita e um executivo que perdeu a confiança em todas elas. Escrevi sobre esse padrão em detalhe em métricas duplicadas: o problema silencioso que mata confiança em BI. O estágio 2 é onde a duplicação começa. Resolver aqui é barato. Resolver no estágio 5 não é.

Estágio 3: o primeiro projeto dbt

Esse é o estágio que todo mundo quer pular, e o que mais determina se a área de analytics do time vai render efeito composto ou patinar. O estágio 3 é um projeto dbt com duas camadas: modelos staging que são 1:1 com as tabelas brutas de origem (colunas renomeadas, tipos convertidos, sem regra de negócio) e um conjunto pequeno de marts que as ferramentas downstream consultam. Testes de grão. Sources definidos. CI em todo PR. É esse o projeto inteiro.

Tristan Handy, fundador da dbt Labs, descreveu a ideia original como "analytics como software, escrito por qualquer pessoa que saiba SQL, para juntar o melhor dos dois mundos de analytics e engenharia". A palavra-chave é "qualquer pessoa que saiba SQL". Você não precisa de um engenheiro de dados para tocar o estágio 3. Precisa de alguém que consiga escrever SELECT e topa versionar no git.

A objeção de custo costuma ser superdimensionada nesse estágio e subestimada no próximo. DuckDB local e o tier gratuito do BigQuery entregam um warehouse funcional a custo mensal zero para um time que está ingerindo só algumas fontes. O tier Free Lite do MotherDuck existe pelo mesmo motivo. As páginas de preço só ficam assustadoras lá na frente da curva, quando jobs de ELT rodam a cada quinze minutos sobre 500 GB de dados e dez usuários de BI batem no warehouse o dia inteiro. Isso não é estágio 3.

O formato dessa faixa é o que importa. O estágio 3 vive nas três primeiras linhas. A última linha é o que o estágio 4 e o estágio 5 começam a custar quando o warehouse vira peça estrutural da empresa toda, ainda irrisório perto do salário de um profissional pleno, mas já fora da casa de "assinatura de café". Os times que tomam um susto são os que orçaram a stack pela primeira linha e acabaram rodando a quinta.

O sinal de que é hora de avançar. Você está no estágio 2 e a duplicação já começou, ou dá pra sentir que vai começar. Alguém perguntou "espera, esse é o mesmo número de receita do deck do board?" e levou noventa minutos para responder.

O que é estrutural. Modelos de staging que espelham as fontes brutas. Testes no grão de cada modelo: unique e not_null na chave primária, relationships em cada chave estrangeira. CI rodando os testes em todo PR. Sources definidos com checagem de freshness. Só isso.

O que é prematuro. Uma camada intermediária. Macros customizadas. O pacote dbt-utils. Snapshots. A semantic layer. Qualquer pasta chamada marts/finance/ quando você tem dois modelos de financeiro. O guia de estrutura da própria dbt Labs é explícito: "Não divida e otimize cedo demais". A maioria dos times lê essa linha e divide assim mesmo.

Modo de falha. Pular o estágio 3 para ir direto ao 4 ou ao 5. Construir marts sem uma camada de staging embaixo, e aí cada modelo de negócio faz o próprio rename e o próprio cast e a mesma coluna acaba definida de quatro formas diferentes pelo projeto. Ou adicionar a Semantic Layer do dbt antes de existir um único modelo de mart que valha a pena expor. O anti-padrão é tão conhecido que Benn Stancil escreveu um ensaio inteiro sobre ele. Nas palavras dele, sobre projetos dbt que deram errado: "Os clientes passaram a ter dificuldade de gerenciar, e muitos projetos dbt viraram emaranhados de Jinja impossível de parsear, modelos Python e SQL entrelaçados, e uma semantic layer incompleta". O emaranhado começa no estágio 3, quando alguém decide que a versão de brinquedo não é sofisticada o bastante.

Estágio 4: a primeira camada de marts

O estágio 4 é quando a camada de staging está estável, os testes estão verdes, e você começa a construir tabelas com significado de negócio. fct_orders. dim_customers. fct_subscription_events. Os nomes são chatos de propósito. Cada mart responde a uma pergunta recorrente que o negócio já faz, e o mart é construído uma única vez, e cada Dashboard, cada analista e cada notebook lê da mesma definição.

A disciplina no estágio 4 é a contenção. Só construa um mart para uma pergunta que alguém está de fato fazendo. Se o financeiro pede receita semanal e o growth pede usuários ativados por semana, você tem dois marts. Você ainda não tem um mart de "customer 360", porque ninguém pediu.

O sinal de que é hora de avançar. Três ou mais Dashboards estão fazendo join direto em tabelas de staging e repetindo a mesma lógica. A sua ferramenta de BI tem a própria view SQL com uma definição de "cliente ativo" que já divergiu da que está no warehouse.

O que é estrutural. Um grão documentado para cada mart (o que cada linha representa, em qual período). Testes no grão. Um único dono por mart. Um doc curto em algum lugar, uma descrição em YAML, um README, uma página no Notion, dizendo para que serve o mart.

O que é prematuro. Subdiretórios tipo marts/finance/, marts/marketing/, marts/product/ quando você tem seis modelos de mart no total. Estratégias incrementais customizadas. Um DAG de modelos intermediários que só existe para deixar os marts "mais limpos".

Modo de falha. Construir um mart para toda pergunta imaginável. Existe uma thread famosa no dbt Discourse em que alguém pergunta à comunidade se 500 modelos em cinco projetos dbt num único repo é normal. Não é. É um time que confundiu "ter um mart" com "responder a uma pergunta". A camada de mart existe para encolher a superfície do warehouse, não para inchá-la.

Aplique essa mediana a uma empresa de 30 pessoas e dá uma pessoa de dados. É nessa restrição que tudo no próximo estágio precisa caber. Governança para um time de uma pessoa não é comitê, é hábito.

Estágio 5: a primeira ferramenta de BI, com governança

O estágio 5 é onde a maioria dos times consolida ou se fragmenta, e a diferença aparece em menos de um ano. A essa altura você já tem um projeto dbt, alguns marts estáveis, e três ou quatro pessoas querendo fazer os próprios gráficos. A pergunta é se eles fazem esses gráficos em cima dos marts ou ao lado deles.

A maioria dos times pequenos já tem uma ferramenta de BI quando chega ao estágio 5. A armadilha não é a ferramenta, é a multiplicação delas. Uma pesquisa de comunidade do Modern Data 101 em 2024 perguntou a times de dados quantas ferramentas distintas eles usam no dia-a-dia, e a distribuição estava enviesada de um jeito que não surpreende quem já viu uma stack de estágio 5 por dentro.

Madison Schott, líder de dados na ConvertKit, resumiu o sintoma na mesma pesquisa: "criar métricas dentro de ferramentas diferentes. E aí você tem três respostas distintas para a mesma pergunta". Esse é o modo de falha do estágio 5 numa frase. A correção ainda não é uma semantic layer, isso é assunto do estágio 6. No estágio 5, a correção é política. Toda métrica que aparece num Dashboard executivo vem de um modelo de mart. Todo usuário de BI que quer uma métrica nova abre um pedido enxuto. O projeto dbt é dono da verdade, e a ferramenta de BI só consome.

O sinal de que é hora de avançar. Duas ferramentas de BI estão em produção e alguém recriou a mesma métrica nas duas. Ou: um executivo pede um número e a primeira pergunta da analista é "de qual Dashboard?".

O que é estrutural. Uma única ferramenta de BI canônica para Dashboards governados. Dono documentado para cada Dashboard. Um agendamento de refresh que alguém de fato confere. Convenções de nomenclatura para Dashboards (do tipo sem graça, mas útil: FIN_, GROWTH_, EXP_). Um doc vivo curto que lista quais métricas vêm do warehouse e quais não vêm, e por quê.

O que é prematuro. Uma semantic layer. Controle de acesso em nível de linha no warehouse inteiro. Um data catalog. Um comitê formal de governança de dados. Você tem onze pessoas. O comitê são duas pessoas num DM no Slack.

Modo de falha. Adicionar uma quarta e uma quinta ferramenta para "consertar" o que na verdade é um problema de definição. O número da Modern Data 101 é um alerta aqui. Cada ferramenta a mais é um lugar a mais onde uma métrica pode brigar com a própria versão. O ensaio do locallyoptimistic Run Your Data Team Like A Product Team descreve a falha vizinha: o time de dados vira balcão de atendimento, atrelado às outras áreas, sem trabalho que renda efeito composto. Um time pequeno no estágio 5 está a uma ou duas decisões ruins de cair nessa trajetória de fábrica de tickets.

Estágio 6: o time toma para si

O estágio 6 é o objetivo, e a maioria dos times pequenos nunca chega lá porque se esgota nos estágios 4 e 5. O sinal do estágio 6 é simples: pessoas que não fazem parte do time de dados estão adicionando modelos, consertando testes e escrevendo documentação. O CFO cita um número do warehouse num update de board sem perguntar a ninguém. O recém-contratado abre um PR no repo do dbt já na segunda semana. As decisões se apoiam no que sai do Dashboard, e não numa thread de prints no Slack.

Isso não acontece por acaso. Acontece quando os estágios 1 ao 5 foram feitos em ordem, quando o conjunto de ferramentas continuou enxuto, e quando quem construiu o projeto ensinou quem entrou depois. A pesquisa da dbt Labs de 2025 encontrou que 80% dos profissionais de analytics estavam usando IA em alguma parte do trabalho, contra 30% no ano anterior. Assistência de IA, Cursor no código de modelagem, um LLM lendo a doc do projeto, um copiloto em análise ad-hoc, acelera o estágio 6 mais do que qualquer estágio anterior, porque a base que ela precisa ler está enfim limpa o suficiente para ser útil. Base ruim mais IA é o pior dos dois mundos.

O sinal de que você está aqui. Quem abriu o último PR relevante foi alguém de fora do time de dados. As perguntas no Slack do tipo "o que essa métrica significa" diminuíram. Receber um recém-contratado no warehouse é uma página escrita, não um despejo verbal de história oral.

O que é estrutural. Documentação. CI rigoroso o suficiente para barrar PR ruim, mas rápido o suficiente para ninguém odiar. Um campo de owner do modelo que de fato é mantido. Um ritual em que, todo mês, alguém revisa a saúde do warehouse, testes que falharam, sources velhos, modelos sem uso, e faz a poda.

O que ainda é prematuro para a maioria dos times. Um time formal de plataforma de dados. Um líder de dados dedicado. Uma cultura de self-service de "qualquer um consulta qualquer coisa" que passa por cima dos marts. O estágio 6 não é "todo mundo é engenheiro de dados". É "o pequeno grupo de pessoas que usa o warehouse confia nele, e um grupo um pouco maior sabe fazer boas perguntas em cima dele".

Modo de falha. Achar que o estágio 6 é permanente. Não é. Um time que chegou ao estágio 6 em 2024 pode estar de volta ao estágio 4 em 2026 se uma pessoa-chave saiu e ninguém retomou o ritual de manutenção. O estágio 6 é um estado, não uma linha de chegada.

A objeção: a gente precisa de algo disso?

A versão mais forte do contra-argumento é essa. O número de 55% da própria pesquisa de 2024 da dbt, em que profissionais de dados dizem que organizar e manter datasets é a tarefa número um, não prova que o trabalho é necessário. Prova que o conjunto de ferramentas de engenharia de analytics criou esse trabalho. Um time pequeno poderia ignorar a escada inteira, rodar relatórios numa planilha, e deixar o fundador pedir SQL ao engenheiro toda vez que precisa de um número.

Esse argumento se sustenta para a primeira dúzia de pessoas. Deixa de se sustentar em algum lugar entre vinte e quarenta. O motivo é que o custo da discordância cresce mais que proporcionalmente. Os números da Synq, lá no começo deste texto, são a restrição: na mediana das scaleups, uma empresa de 30 pessoas tem uma pessoa de dados. Essa pessoa não pode ser o único lugar onde a verdade mora. Ou o warehouse é dono da verdade e essa pessoa cuida dela, ou cada time é dono da própria e a empresa começa a rodar com números que se contradizem. Do estágio 3 em diante é a opção mais barata das duas, e fica mais barata quanto antes começar.

A outra observação de Dengsøe é o corretivo: "Se você investe demais em cargos analíticos, corre o risco de desacelerar todo mundo à medida que a qualidade da plataforma de dados começa a piorar". Contratar três analistas para tapar o buraco de um estágio 3 que não existe não funciona. A plataforma vem primeiro. Os analistas multiplicam, não substituem.

Em qual estágio você está, na verdade?

A resposta honesta, para a maioria dos times, é um estágio antes do que eles imaginam. Os sinais são operacionais, não aspiracionais. Algumas perguntas para se fazer, em ordem:

• Duas pessoas do seu time conseguem chegar ao mesmo número de receita do trimestre passado sem combinar antes? Se não, você está no estágio 1 ou 2, não importa quais ferramentas você comprou.
• Quando alguém pergunta "de onde vem esse número?", a resposta é uma query que dá pra ler ou uma planilha que alguém precisa lembrar de cabeça? Se for a segunda, você está no estágio 1.
• Cada Dashboard em que você confia lê de um modelo definido num warehouse, ou metade deles lê de uma réplica transacional com SQL feito sob medida? Se for a segunda, você está em algum lugar entre o estágio 2 e o 3, o SQL sob medida é a duplicação começando.
• Se você abrisse o seu projeto dbt agora (supondo que tem um), existe um diretório staging/ com um modelo por fonte bruta, e esses modelos só fazem rename e cast? Se não, você é estágio 3 no nome e estágio 2 na prática.
• Quando alguém fora do time de dados precisa de uma métrica nova, existe um caminho que não passa por esperar o único engenheiro que conhece o warehouse? Se não, você está no estágio 4 na melhor das hipóteses, não importa quantos marts construiu.
• Alguém de fora do time de dados deu commit no projeto dbt no último trimestre? Se não, você não está no estágio 6, por mais sofisticado que o projeto seja.

Fique com o estágio mais baixo que qualquer uma dessas perguntas apontar. É onde você está. A tentação, ainda mais depois de ler um texto como esse, é pular para frente e atacar a falha mais interessante. Resista. Os times que rendem efeito composto são os que fizeram o estágio 3 direito antes de mexer no 4, e o estágio 4 direito antes de mexer no 5. Os times que não rendem são os que têm uma semantic layer pela metade em cima de uma camada de staging que nunca foi terminada.

Fontes

Estatísticas de download do dbt-core no PyPI, abril de 2026: pypistats.org; o número de 90.000 projetos em produção foi citado no Coalesce 2025 e reportado por Hugo Lu em DataOps Leadership.

Pesquisas State of Analytics Engineering da dbt Labs: a edição de 2024 (n=456), em que 55% dos profissionais de dados apontam organizar e manter datasets como tarefa número um, está em getdbt.com; a edição de 2025 (n=459), 56% citando qualidade de dado como o desafio principal, 80% usando IA no fluxo de trabalho contra 30% no ano anterior, está em State of Analytics Engineering 2025. Vale lembrar que as pesquisas da dbt Labs recrutam pelos canais do próprio dbt, então esses números puxam para o lado da população de profissionais já inclinado ao dbt.

Análise de Mikkel Dengsøe sobre tamanho de time de dados em 100 scaleups dos EUA e Europa, com a mediana de 3% do total de funcionários: blog da Synq.

Pesquisa de comunidade da Modern Data 101 sobre complexidade de stack de dados (n=230+, 2024), fonte para os 70% lidando com 5–10 ferramentas e 63% gastando mais de 20% do tempo em manutenção de stack, incluindo a citação de Madison Schott sobre métricas duplicadas: The Current Data Stack Is Too Complex.

Tristan Handy enquadrando engenharia de analytics, entrevista para a First Round Review, 2024; Benn Stancil sobre os modos de falha do dbt em benn.substack.com; a orientação de estrutura de projeto da dbt Labs e a regra "não divida e otimize cedo demais" vêm de How We Structure Our dbt Projects.

Sobre rodar um time pequeno de dados sem virar uma loja de tickets: Run Your Data Team Like A Product Team (Locally Optimistic). A thread no dbt Discourse sobre um projeto de 500 modelos em cinco projetos dbt: Amount of models in one project for one team.

Referências de preço de warehouse, todas de abril de 2026: BigQuery, MotherDuck pricing change 2026, Snowflake pricing, e MotherDuck data warehouse TCO.

Leitura relacionada

Para o menor projeto dbt viável, convenções de staging, a regra de quatro testes, CI desde o dia um, veja dbt para times pequenos: como começar sem complicar. Para o modo de falha de duplicação que estágios 4 e 5 existem para combater, veja métricas duplicadas: o problema silencioso que mata confiança em BI. Para o porquê de tudo isso importar antes de você botar uma feature de IA em cima, veja arrume seus dados antes de adotar IA generativa.