BI sem um data lake

A maioria dos projetos de BI em startups começa cedo demais e grande demais.

Um fundador faz uma pergunta simples: "Os usuários deste canal estão voltando depois da primeira execução?" A resposta deveria ser uma query. Em vez disso, ela costuma virar um projeto de plataforma: conectar todas as fontes, construir um data warehouse, definir eventos, limpar identidades, montar dashboards e esperar.

Esse trabalho acaba importando, sim. Mas, para um time pequeno, pode ser o primeiro passo errado. O banco de dados do produto já sabe quase tudo o que o fundador precisa saber. Ele sabe quem se cadastrou, quem executou algo, o que usaram, quanto custou, o que falhou e se voltaram.

O verdadeiro problema não é onde a verdade está. É como permitir que um agente analise essa verdade sem expor o banco de dados de produção bruto.

Esse é o padrão que usamos na VM0: uma branch do Neon mascarada e somente leitura, que dá aos nossos agentes verdade suficiente para rodar BI, sem lhes dar os dados que eles nunca deveriam ver.

O problema do fundador: as perguntas chegam antes do time de dados

Empresas em estágio inicial não carecem de perguntas. Elas carecem de tempo.

Todos os dias, o time fundador quer saber coisas como:

• O tráfego de ontem virou usuários de verdade?
• Quais canais de cadastro geram pessoas que de fato executam algo?
• Os usuários de primeira execução voltam depois de 7 ou 30 dias?
• Quais contas pagas estão ficando inativas?
• Qual rota de modelo está puxando o custo?
• Os abusadores de trial estão queimando computação antes de converter?
• A saúde do produto melhorou ou piorou desde ontem?

Nenhuma dessas perguntas é exótica. Elas são o ritmo operacional de uma startup.

Mas respondê-las com o manual tradicional de BI cria muita sobrecarga. Você geralmente começa movendo dados do banco do produto para outro sistema. Depois normaliza, define métricas, reconstrói relacionamentos e monta dashboards. O time ganha uma stack de analytics mais limpa, mas o fundador muitas vezes espera dias ou semanas por uma resposta que poderia ter começado como uma query SQL.

Para uma startup pequena, essa troca pode estar de cabeça para baixo. Você não precisa de uma plataforma de dados completa para fazer suas primeiras 20 perguntas operacionais. Você precisa de uma forma segura de consultar a fonte da verdade que já tem.

O banco de dados já é a fonte da verdade

Na VM0, o banco de dados do produto contém os fatos que importam para muitas decisões em nível de fundador:

• Organizações e usuários
• Estado de cadastro e de assinatura
• Execuções e agendamentos de agentes
• Consumo de créditos e eventos de uso
• Modelos selecionados e rotas de provedores
• Estado dos connectors
• Estado de falhas e timestamps

Esses relacionamentos já estão ali. Eles são mais frescos do que qualquer dashboard downstream e refletem como o produto realmente funciona.

Isso importa porque muitas perguntas iniciais de BI são relacionais. Um fundador não quer apenas page views ou contagem de execuções. Ele quer conectar o comportamento ao longo do sistema:

Dos usuários que se registraram por este canal, quantos executaram algo no dia zero e quantos voltaram depois da primeira execução?

Ou:

Quais organizações pagas não executaram nada nos últimos 7 dias, e antes pareciam ativas?

Ou:

Quanta computação as novas contas de trial queimaram nas suas primeiras 6 horas, antes e depois de mudarmos nosso patrulhamento de abuso?

Essas perguntas se encaixam naturalmente no banco de dados do produto. Elas ficam muito mais difíceis quando toda resposta começa movendo dados para uma plataforma separada.

O atalho inseguro é o acesso bruto à produção

O atalho tentador é óbvio: basta deixar o agente consultar a produção.

Isso não é aceitável.

Um banco de dados de produção pode conter o material mais sensível da empresa: endereços de e-mail, prompts, conteúdo de chats, credenciais, estado criptografado de provedores, logs, mensagens de erro, chaves de API e registros operacionais internos. Mesmo que um agente seja cuidadoso, o acesso bruto cria um problema de fronteira. O agente consegue ver demais. Um erro em uma query, em um relatório ou em uma captura de tela pode vazar informações que o time nunca pretendeu expor.

O acesso de escrita é ainda pior. O BI não deveria ser capaz de alterar a produção. Um analista, humano ou agente, não deveria estar a um comando errado de distância de modificar dados de usuários.

Então a questão não é se os agentes conseguem escrever SQL. Eles conseguem. A questão é se você consegue lhes dar verdade suficiente para serem úteis, mantendo privacidade e segurança como restrições rígidas.

Para nós, essas restrições são o ponto central:

• Os agentes não devem ver prompts brutos.
• Os agentes não devem ver e-mails brutos.
• Os agentes não devem ver credenciais ou segredos.
• Os agentes não devem ver logs sensíveis em texto livre.
• Os agentes não devem ter acesso de escrita à fonte de BI.
• O time fundador ainda deve conseguir fazer perguntas operacionais práticas rapidamente.

Essa é a forma do sistema de que precisávamos.

O meio-termo seguro: um banco de dados mascarado e somente leitura

O Neon torna um padrão útil possível porque as branches são cópias baratas e isoladas de um banco de dados Postgres. Você pode criar uma branch parecida com a produção, transformá-la e expor essa branch em vez da produção em si.

Na VM0, usamos isso para criar o que chamamos de MaskDB.

O fluxo é simples:

1. Partir da branch pai de produção no Neon.
2. Criar uma branch nova de forma agendada.
3. Instalar o PostgreSQL Anonymizer e os auxiliares de mascaramento específicos da VM0.
4. Aplicar security labels nas colunas sensíveis.
5. Rodar a anonimização estática na branch.
6. Aplicar máscaras personalizadas finais para campos que precisam de tratamento especial.
7. Criar um role masked_readonly com acesso SELECT.
8. Deixar os agentes consultarem esse role, não a produção.

O detalhe importante é que o mascaramento é estático. Os valores sensíveis são reescritos na branch mascarada antes de o agente se conectar. Isso é diferente de pedir a cada query downstream que lembre o que não deve selecionar. A própria branch é a fronteira.

No nosso MaskDB, credenciais e segredos são removidos. E-mails e números de telefone são parcialmente mascarados. Conteúdo de usuário, como prompts, mensagens de chat, prompts de agendamentos e saídas de agentes, é removido. O texto de erro é reduzido a uma classe em vez de um stack ou mensagem completos. Tabelas que nunca deveriam aparecer na análise podem ser descartadas por inteiro.

Ao mesmo tempo, identificadores opacos como org_id, user_id e clerk_user_id continuam passíveis de join. É isso que torna o BI possível. Não precisamos que o agente saiba o e-mail de uma pessoa ou o texto de um prompt. Precisamos que ele saiba que a mesma organização se registrou, executou uma tarefa, consumiu créditos, assinou, ficou dormente ou voltou mais tarde.

Esse equilíbrio é todo o objetivo: mascarar o material legível por humanos e sensível, preservar a espinha relacional.

O que os agentes podem fazer quando a fronteira existe

Uma vez que o banco mascarado e somente leitura existe, o agente consegue se tornar útil muito rapidamente.

Ele pode fazer perguntas diretamente sobre os dados do produto:

• Retenção de usuários de 7 e 30 dias
• Ativação do cadastro até a primeira execução
• Retenção ancorada na primeira execução
• Dormência de organizações pagas
• Estado de assinatura e monitoramento de churn
• Uso de modelos por modelo selecionado
• Rotas nativas vs. rotas de provedor do usuário
• Consumo de computação em trial
• Custo por execução por modelo
• Taxa de falha e taxa de conclusão por coorte

Ele também pode combinar essa verdade do banco com os sistemas ao redor.

Nosso Morning Brief puxa do Plausible, do Axiom, do Sentry, do Google Ads, do GitHub e de outras fontes operacionais. O banco de dados nos diz o que usuários e organizações fizeram. O Plausible nos diz o que aconteceu no site. O PostHog pode ajudar com o contexto de eventos de produto. O Axiom nos diz o que aconteceu nos logs e nos caminhos de requisição. O Sentry captura os erros. O Stripe e o Clerk ajudam a explicar cobrança e identidade. O GitHub mostra a vazão de engenharia.

A ideia não é substituir cada ferramenta por SQL. A ideia é deixar o agente conectar os fatos com que os fundadores de fato se importam.

Por exemplo:

O Google pago enviou mais tráfego do que o orgânico ontem. Esses usuários realmente chegaram à primeira execução, ou pararam no topo do funil?

Ou:

Mudamos o patrulhamento de abuso de trial. As novas contas de trial queimaram menos computação nas suas primeiras horas?

Ou:

Essa rota de modelo é mais barata por execução. Isso aparece no uso histórico real de chats, ou só na teoria de preços?

Essas não são perguntas de dashboard. São perguntas operacionais. Elas mudam de semana para semana, às vezes de dia para dia. Um agente com acesso seguro ao banco de dados pode respondê-las sem pedir à engenharia para construir uma nova view toda vez.

Um exemplo real: retenção e saúde de usuários externos

Uma das nossas análises internas diárias observa a saúde de usuários externos nas últimas 24 horas.

O relatório parte do MaskDB e então aplica um conjunto rígido de exclusões. As organizações internas da VM0 são removidas. Organizações de spam banidas ou bloqueadas no Clerk são removidas. Esse mesmo conjunto de exclusões é aplicado em todo lugar, incluindo contagens de cadastro e coortes de retenção, para que os denominadores permaneçam auditáveis.

A partir daí, o agente consegue produzir um relatório operacional compacto:

• Execuções e organizações externas ativas
• Taxa de conclusão
• Mix de gatilhos entre web, CLI, agendamentos e rotas fora do Zero
• Mix de modelos
• Modo de provedor
• Atividade de organizações pagas
• Organizações pagas dormentes
• Novos cadastros pagos e organizações em trial
• Monitoramento de churn
• Segmentação de usuários de 30 dias
• Retenção do cadastro até a execução
• Retenção da primeira execução

Esse é exatamente o tipo de relatório de que um time fundador precisa. Ele não exige prompts brutos. Não exige e-mails brutos. Não exige acesso de escrita à produção.

Ele exige, sim, a capacidade de juntar os fatos do produto corretamente.

Em uma execução, o agente descobriu que um pequeno número de organizações externas ativas estava puxando a maior parte do volume, que várias organizações pagas tinham ficado inativas e que coortes de cadastro recentes mostravam uma queda brusca de ativação, provavelmente causada por cadastros de spam inflando o denominador. Esse é o tipo de coisa que um fundador deveria ver rapidamente, não descobrir semanas depois em uma revisão de dashboard.

Um segundo exemplo: a economia do abuso de trial

Dados de produto mascarados também são úteis para perguntas que não são gráficos clássicos de BI.

Quando analisamos o abuso de trial, a métrica útil não era o total de computação gasto. O gasto total seria enviesado em favor de contas mais antigas, porque elas tiveram mais tempo para consumir créditos. A pergunta melhor era:

Quanta computação de trial uma conta nova queima nas suas primeiras horas após o cadastro?

Usando o MaskDB, o agente mediu o consumo de computação em janelas correspondentes após o registro. Ele usou o consumo de créditos a partir dos eventos de uso, os timestamps de registro a partir dos metadados da organização e o estado de assinatura para separar a economia de trial do uso pago.

Depois que o patrulhamento entrou no ar, a média de computação de trial queimada nas primeiras horas após o cadastro caiu mais de 80%. A cauda de consumo pesado quase desapareceu. No percentil 90, a computação de trial das primeiras horas caiu de cerca de US$ 4,05 para cerca de US$ 0,26, uma queda de 94%.

Esse número não é apenas um dado de analytics. Ele muda a visão operacional do negócio. Ele diz ao time fundador que o abuso não estava só sendo detectado, mas que a economia unitária do trial estava se movendo na direção certa.

E isso foi possível porque o banco de dados tinha a verdade, enquanto a branch mascarada tornava seguro para um agente analisar essa verdade.

Um terceiro exemplo: custo de modelo no produto real

Páginas de preços e planilhas de benchmark são úteis, mas não respondem à pergunta com que os fundadores de fato se importam:

Quanto este modelo custa no nosso produto real, ao longo de execuções reais?

Usando o MaskDB, o agente comparou execuções históricas de chat juntando os registros de execução com o modelo selecionado no momento da execução e agregando os créditos cobrados a partir dos eventos de uso.

Essa distinção importa. Você não deveria atribuir execuções históricas usando o provedor de modelo padrão atual do usuário, porque os padrões mudam. O modelo selecionado no momento da execução é a fonte da verdade.

Na nossa análise, o DS v4 Pro teve um custo mediano de créditos de modelo por execução de chat que era cerca de 49% do custo do Sonnet. Em outras palavras, a execução de chat mediana real saía cerca de 51% mais barata nessa rota.

De novo, isso é BI em nível de fundador. Ele conecta comportamento de produto, custo de infraestrutura e estratégia de modelo. Não exige um novo warehouse. Exige acesso seguro aos dados relacionais certos.

Isso não é um substituto definitivo para um warehouse

Existe um ponto em que uma empresa precisa de uma stack de dados mais formal.

Quando as métricas precisam de uma governança semântica forte, quando muitos times dependem das mesmas definições, quando os backfills históricos ficam complexos, quando os dashboards passam a fazer parte do sistema operacional, um warehouse ou lakehouse pode ser a resposta certa.

Mas muitas startups buscam essa resposta cedo demais.

Se você é um time fundador pequeno, seu primeiro sistema de BI deveria ajudá-lo a responder perguntas, não criar um segundo produto para manter. Um banco de dados mascarado pode ser a ponte. Ele não está fingindo que a modelagem de dados não importa. Ele está reconhecendo que o banco do produto já contém os relacionamentos de que você precisa para o próximo conjunto de decisões.

O agente não elimina a necessidade de julgamento. Ele torna a primeira versão da análise mais barata de rodar.

O padrão para times fundadores

O padrão é simples:

1. Trate o banco de dados do produto como a primeira fonte da verdade.
2. Nunca exponha a produção bruta aos agentes.
3. Use uma branch parecida com a produção, não um conjunto de dados de amostra montado à mão.
4. Mascare estaticamente as colunas sensíveis antes do acesso.
5. Preserve identificadores opacos de join para que a análise ainda funcione.
6. Exponha a branch por meio de um role somente leitura.
7. Deixe os agentes rodarem o ciclo de analista entre o banco mascarado e as ferramentas ao redor.

Isso dá a um time fundador um sistema operacional útil sem precisar construir uma plataforma de dados completa primeiro.

Também cria uma postura de segurança mais limpa. O agente tem uma fronteira rígida. O banco que ele vê já foi transformado. O role que ele usa não pode escrever. Os relatórios que ele produz podem ser limitados a identificadores com hash ou agregados.

Esse é o equilíbrio que queríamos na VM0: privacidade e segurança como piso, não como troca, ao mesmo tempo em que damos ao time fundador uma forma muito mais rápida de entender o negócio.

Antes de construir um data lake, pergunte se uma branch mascarada e somente leitura do seu banco de dados de produto consegue responder às próximas 20 perguntas que o seu time realmente tem.

Para nós, esse foi o caminho mais rápido até o BI.

Fontes

• Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
• Fork do PostgreSQL Anonymizer pela Neon: https://github.com/neondatabase/postgresql_anonymizer