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 cru 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 entre agora e lá é 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 variantes 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. Operadores brasileiros e dos EUA/Europa misturados. Já pagam por pelo menos uma ferramenta de BI. Já discutem qual número de receita é o correto.

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 dominante em todos os estágios é o mesmo: pular etapas. Queimar meses em uma semantic layer antes do 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 fala isso de forma direta: "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 ignora essa linha no dia um.

O trabalho, em outras palavras, é majoritariamente encanamento. O modelo de maturidade abaixo é um argumento sobre qual encanamento vale 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 lá 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 é genuinamente a resposta certa. Não tem infraestrutura para manter, nem migração de schema, nem SQL para escrever, e o ciclo de iteração é de dois segundos.

Não tenho um número defensável de quantas empresas pequenas vivem em planilhas. As pesquisas publicadas todas amostram quem já se identifica como profissional de dados, o que enviesa a resposta. Mas todo operador com quem trabalhei abaixo de trinta funcionários roda pelo menos 60% do reporting via Sheets ou Excel, e esse não é o modo de falha. O modo de falha é o que eles fazem em seguida.

O sinal de que é hora de avançar. A mesma planilha foi editada por quatro pessoas esse mês e duas delas começaram a copiar antes de mexer. Ou: um número em que você confiou no trimestre passado agora está errado, e ninguém consegue reconstruir o porquê. Ou: você precisa explicar para um novo contratado qual aba é a visão "real" do pipeline. Quando a planilha começa a ser bifurcada em vez de compartilhada, você 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 é glamoroso, e pular isso é o que cria o caos que depois vai ser jogado na conta dos warehouses por não terem resolvido.

O que é prematuro. Um warehouse. Uma ferramenta de BI. dbt. Qualquer pessoa 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 mandou. A conta do mês um é pequena, a conta do mês seis não é, e o time continua fazendo o reporting na mesma planilha porque o warehouse nunca foi populado.

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. Geralmente isso significa que alguém (frequentemente um engenheiro de backend que cansou de ser perguntado) 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 executando 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 fio comum é que a definição da métrica vive em código que alguém pode revisar, não em uma planilha que alguém pode reescrever sem te avisar.

O sinal de que é hora de avançar. Você tem mais de dez dessas queries. Duas delas discordam sobre a mesma métrica. Ou você começou a copiar 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 seja lá quais sejam as suas). Um agendamento, mesmo que seja um cron amarrado com fita.

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

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 agora você tem três definições de receita e um executivo que parou de confiar em qualquer uma. 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. Pegar aqui é barato. Pegar no estágio 5 não é.

Estágio 3: o seu primeiro projeto dbt

Esse é o estágio que todo mundo quer pular, e o que mais determina se a função de analytics do time vai compor ou se debater. 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 operar o estágio 3. Precisa de alguém que consiga escrever SELECT e esteja disposto a colocar no git.

A objeção de custo costuma ser exagerada 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 ficam assustadoras mais para cima na 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 todo. Isso não é estágio 3.

O formato dessa faixa é o ponto. O estágio 3 vive nas três primeiras linhas. A última linha é o que estágio 4 e estágio 5 começam a custar quando o warehouse passa a ser estrutural para a empresa toda — ainda trivial comparado a um salário de pessoa pleno, mas já fora da casa de "assinatura de café". Os times que tomam um susto são aqueles que precificaram a stack contra a 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 você sente que ela vai começar. Alguém perguntou "espera, esse é o mesmo número de receita do deck do board?" e a resposta levou noventa minutos para ser produzida.

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 mesmo assim.

Modo de falha. Pular o estágio 3 para ir direto ao 4 ou ao 5. Construir marts sem uma camada de staging embaixo, então 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 expor. O anti-padrão é documentado o suficiente para Benn Stancil ter escrito um ensaio inteiro sobre isso. 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 sua 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 entediantes de propósito. Cada mart responde a uma pergunta recorrente que o negócio já está fazendo, e o mart é construído uma vez para que cada Dashboard, cada analista e cada notebook leiam 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 semanal, você tem dois marts. Você ainda não tem um mart de "customer 360", porque ninguém está pedindo.

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

O que é estrutural. Um grão documentado para cada mart (uma linha por o quê, por qual período de tempo). 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 o mart serve.

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 existe só para deixar os marts "mais limpos".

Modo de falha. Construir um mart para cada pergunta concebível. Existe uma thread famosa no dbt Discourse em que um praticante pergunta à comunidade se 500 modelos em cinco projetos dbt num único repo é normal. Não é normal. É um time que confundiu "ter um mart" com "responder a uma pergunta". A camada de mart existe para comprimir a superfície do warehouse, não para expandir.

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

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

O estágio 5 é onde a maioria dos times consolida ou fragmenta, e a diferença aparece dentro 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 proliferação. 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 deveria surpreender 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 é território do estágio 6. A correção no estágio 5 é 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 pequeno. O projeto dbt é dono da verdade, e a ferramenta de BI consome.

O sinal de que é hora de avançar. Duas ferramentas de BI estão em produção e alguém reproduziu 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. Propriedade documentada para cada Dashboard. Um agendamento de refresh que alguém de fato confere. Convenções de nomenclatura para Dashboards (do tipo sem charme mas útil: FIN_, GROWTH_, EXP_). Um doc vivo curto que lista as métricas que vêm do warehouse versus as que não vêm, e por quê.

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

Modo de falha. Adicionar uma quarta e quinta ferramenta para "consertar" o que na verdade é um problema de definição. O número da Modern Data 101 é um aviso aqui. Cada ferramenta extra é um lugar a mais onde uma métrica pode discordar de si mesma. O ensaio do locallyoptimistic Run Your Data Team Like A Product Team descreve a falha adjacente: o time de dados vira service desk, parafusado em outras funções, sem trabalho que componha. Um time pequeno no estágio 5 está a uma ou duas decisões ruins de cair nessa trajetória de loja de tickets.

Estágio 6: o time é dono disso

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 marcador 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. O novo contratado abre um PR contra o repo do dbt na segunda semana. Decisões referenciam saída de Dashboard em vez de uma thread de prints no Slack.

Isso não acontece por acidente. Acontece quando os estágios 1 ao 5 foram feitos em ordem, quando o conjunto de ferramentas continuou enxuto, e quando as pessoas que construíram o projeto ensinaram 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 o andaime que ela precisa ler está finalmente limpo o suficiente para ser útil. Andaime ruim mais IA é o pior dos dois mundos.

O sinal de que você está aqui. Uma pessoa fora do time de dados abriu o último PR relevante. O número de perguntas no Slack do tipo "o que essa métrica significa" caiu. Onboardar um novo contratado no warehouse é uma página escrita, não um despejo verbal de lore.

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

O que ainda é prematuro para a maioria dos times. Um time formal de plataforma de dados. Uma cabeça de dados dedicada. Uma cultura de self-service de "qualquer um consulta qualquer coisa" que contorna os 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".

Modo de falha. Acreditar 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 substituiu o ritual de manutenção. Estágio 6 é um estado, não um ponto final.

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

A versão mais forte do contra-argumento é assim. 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 é sinal de que o trabalho é necessário. É sinal de que o conjunto de ferramentas de engenharia de analytics inventou o trabalho. Um time pequeno poderia ignorar a escada inteira, rodar relatórios numa planilha, e deixar o fundador pedir SQL ao engenheiro quando precisa de um número.

Esse argumento se sustenta para a primeira dúzia de pessoas. Para de se sustentar em algum lugar entre vinte e quarenta. O motivo é que o custo da discordância cresce de forma super-linear. Os números da Synq mais cedo nesse 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 vive. Ou o warehouse é dono da verdade e ela cura, ou cada time é dono da própria e a empresa começa a rodar com números contraditórios. 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ê sobre-investe em papéis analíticos, corre o risco de desacelerar todo mundo na medida em que a qualidade da plataforma de dados começa a deteriorar". Contratar três analistas para tapar a ausência de um estágio 3 não funciona. A plataforma vem primeiro. Os analistas são o multiplicador, não o substituto.

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 fazer, em ordem:

• Duas pessoas do seu time conseguem produzir o mesmo número de receita do trimestre passado sem se ligarem? Se não, você está no estágio 1 ou 2, independentemente de quais ferramentas você comprou.
• Quando alguém pergunta "de onde vem esse número?", a resposta é uma query que alguém pode ler ou uma planilha que alguém precisa lembrar? Se for a segunda, você está no estágio 1.
• Cada Dashboard em que você confia lê de um modelo definido em um 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 estágio 2 e 3 — o SQL sob medida é a duplicação começando.
• Se você abrisse o seu projeto dbt agora (assumindo 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 uma pessoa fora do time de dados precisa de uma métrica nova, existe um caminho que não envolve esperar pelo único engenheiro que conhece o warehouse? Se não, você está no estágio 4 no melhor dos casos, independentemente de quantos marts construiu.
• Alguém fora do time de dados commitou no projeto dbt no último trimestre? Se não, você não está no estágio 6, mesmo que o projeto seja sofisticado.

Pegue o estágio mais baixo apontado por qualquer dessas perguntas. É onde você está. A tentação, especialmente depois de ler um texto como esse, é pular adiante e atacar a falha mais interessante. Resista. Os times que compõem são os que fizeram o estágio 3 direito antes de tocar no 4, e o estágio 4 direito antes de tocar no 5. Os times que não compõem são os com 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) reportando que 55% dos profissionais de dados nomeiam 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 dbt, então esses números refletem o lado da população de profissionais que tende 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.