Kaiju: as métricas do seu SaaS, plugadas no seu banco
Todo mundo que trabalha com dados numa empresa já recebeu este pedido:
"Preciso do faturamento por região, com o mês passado do lado, e quero que o comercial veja também. Só isso, não o resto."
Não tem nada difícil ali. É um agrupamento, um filtro de data e uma regra de quem vê o quê. Ainda assim isso vira card no backlog, reunião de alinhamento, analista escrevendo a query à mão e, quando o prazo aperta, uma planilha no e-mail para sete pessoas.
O custo dessa fila não é o relatório que atrasou. É a pergunta que ninguém faz.
Quando pedir um número custa duas semanas, as pessoas param de pedir. Elas decidem com o que já têm na mão, que costuma ser a planilha do trimestre passado e a intuição de quem está há mais tempo na casa. A empresa não fica sem dados. Fica sem o hábito de consultar os dados, o que é uma perda muito mais cara e muito mais silenciosa.
E existe um motivo real para essa fila existir. Ninguém segura acesso por prazer. Segura porque a alternativa é dar credencial de leitura do banco de produção para dez pessoas e torcer. Quem já viu uma query mal escrita travar o sistema numa sexta à tarde não repete o experimento (fatos verídicos).
O Kaiju existe para acabar com essa escolha entre lento e arriscado. É uma plataforma de métricas que pluga no banco da empresa, sincroniza para um lake próprio e devolve painel, API e embed. A tese do produto é uma só: liberdade total em cima, isolamento real embaixo.
Abaixo está o que isso resolve, em ordem de impacto no negócio, com o "como fazer" técnico em cada bloco para quem quiser conferir.
1. Quem sabe SQL vira autor, não solicitante
O problema de negócio. Toda empresa tem duas ou três pessoas fora do time de dados que sabem escrever SQL. Hoje elas são tratadas como solicitantes, igual a todo mundo. É desperdício puro: a pessoa que consegue escrever a resposta fica na fila esperando outra pessoa escrever a resposta.
O que o Kaiju entrega. Um editor SQL dentro do painel. A pessoa escreve a query, vê o resultado na hora e clica em "converter em medida". Aquilo vira um objeto reutilizável, que qualquer um pode arrastar para um card, consumir pela API ou embutir num sistema próprio.
Como fazer. O SQL do usuário nunca toca a fonte de produção, só o lake em Parquet. No "converter em medida", o worker roda um EXPLAIN do statement antes de persistir: se não compila, não salva. Nesse mesmo passo ele registra quais tabelas do lake a query referencia, informação que vai fazer falta no bloco 3. A medida fica no metadata do servidor, não no navegador de quem criou, porque validação, revalidação e execução escopada são todas responsabilidades de servidor.
2. O dado de um cliente não alcança o outro, nem por acidente
O problema de negócio. Esse é o item que decide se a diretoria aprova a ferramenta. "Liberar SQL" soa como abrir a porta.
O que o Kaiju entrega. Cada execução de SQL de usuário roda numa sessão que, fisicamente, não tem permissão de ler o dado de outro cliente.
Como fazer. A sessão é montada em ordem, e a ordem é o controle:
- Conexão DuckDB nova, isolada.
- Credencial efêmera por tenant, emitida via STS com session policy limitada ao prefixo
lake/{tenant}/*. Se a query pedir o caminho do vizinho, o storage responde 403 antes de qualquer coisa. - Views criadas por nome lógico. O usuário escreve
FROM pedidos, nunca um path cru de arquivo. - Limites de recurso (bloco 5) e restrição de filesystem local.
lock_configuration=truecomo último passo. Depois disso o SQL do usuário não troca credencial, não reabre filesystem e não sobe limite nenhum.- Allowlist de statement pelo parser: um único
SELECT, semATTACH,COPY,INSTALLouPRAGMA.
Um detalhe que vale registrar porque custou tempo: o flag que "desliga acesso externo" do DuckDB parece a trava perfeita e é inútil aqui, porque desligaria o próprio httpfs de que as views dependem. A trava real é a credencial por prefixo, não o flag.
E a regra que amarra o modelo: validar não concede confiança de execução. Preview do editor, card do painel, embed e API executam todos pela mesma sessão escopada, sem atalho de "essa medida já foi validada, pode rodar direto". Cada caminho alternativo seria uma cópia da regra de isolamento para manter em sincronia, e cópia de regra de segurança envelhece mal.
3. O número criado hoje continua certo em três meses
O problema de negócio. Ferramenta de autoatendimento não morre no lançamento, morre no terceiro mês. O sistema de origem muda, uma coluna some, e as medidas que as pessoas criaram começam a falhar em silêncio ou a mostrar erro cru dentro do card. A partir daí ninguém confia mais em nada que não tenha vindo do time de dados, e a fila volta.
O que o Kaiju entrega. Medida quebrada é um estado do produto, com nome e tratamento, não uma surpresa no meio da reunião.
Como fazer. Quando um sync altera o schema de uma tabela, a versão de schema daquela tabela sobe. O sistema reexecuta o EXPLAIN das medidas que referenciam aquela tabela (a lista registrada no bloco 1). Se falhar, a medida entra em status = broken com o erro guardado, e o card mostra "medida quebrada, reabra no editor" em vez de stack trace. Autoria sem manutenção não é autonomia, é dívida repassada para o usuário final.
4. Todo mundo vê o mesmo número, e ele é de hoje
O problema de negócio. Dois gestores abrem o mesmo painel e leem valores diferentes. Isso destrói a credibilidade da ferramenta mais rápido que qualquer bug visível, porque não parece bug: parece que o dado é confuso.
O que o Kaiju entrega. Cache agressivo, porque velocidade importa, sem o efeito colateral de mostrar o dado de ontem hoje.
Como fazer. A chave de cache inclui o watermark de sync do tenant, além do identificador da medida e dos parâmetros. Sync bem sucedido incrementa a versão do dataset, e todo cache que dependia da versão anterior deixa de valer por consequência, não por rotina de limpeza que alguém precisa lembrar de rodar. O pior bug de dados não é o que falha, é o que responde com confiança.
5. A curiosidade de um não derruba o dia dos outros
O problema de negócio. O medo mais concreto de quem opera a infraestrutura: alguém escreve um cruzamento pesado por engano e a plataforma inteira sente.
O que o Kaiju entrega. O erro fica contido em quem o cometeu, e volta legível.
Como fazer. Limites por sessão: teto de memória abaixo do limite do container, teto de threads, teto de linhas imposto pelo worker e timeout por conexão, com interrupção real da query. Cada fonte carrega o próprio query_timeout_ms, com teto máximo definido no servidor.
A decisão que começou como segurança e virou produto: no timeout, a resposta devolve o SQL que rodou, o tempo gasto e o log cru. Erro opaco faz a pessoa desistir e voltar a pedir para o time de dados. Erro legível faz ela consertar o próprio JOIN e continuar. Limite por sessão é o que transforma "usuário roda SQL" de risco operacional em recurso normal do produto.
6. Compartilhar sem multiplicar risco
O problema de negócio. Volta ao pedido do começo: "quero que o comercial veja também, só isso, não o resto". É onde a maioria das ferramentas entrega um sim pela metade, escondendo o menu na interface enquanto a API continua aberta para quem souber chamar.
O que o Kaiju entrega. Permissão por tela, valendo também para os dados, não só para o botão.
Como fazer. A autorização vive no gateway, o único caminho por onde toda leitura passa, com papéis-preset que expandem em grants e grant explícito por recurso para o caso "vê só as telas X e Y". O frontend só esconde botão, e esconder botão é experiência, nunca fronteira.
A inversão que fecha o vetor de dados: o usuário restrito não pede "execute esta medida". Ele pede "renderize o widget 3 da tela que eu posso ver". A especificação do widget vem do banco, nunca do corpo da requisição. Consequência de graça: a autorização da medida passa a ser a autorização da tela que a usa, sem tabela de permissão por medida e sem sincronizar grants a cada edição.
7. Quem não sabe SQL também autora
O problema de negócio. Os blocos anteriores servem a quem escreve SQL. A maior parte da empresa não escreve, e é justamente ela que mais depende da fila.
O que o Kaiju entrega. O Ghidora, um agente que conversa em português, entende o schema, propõe medidas e monta telas.
Como fazer. O agente pode gerar quantos SELECT quiser, e todos passam pela mesma sessão escopada do bloco 2. Autoria é insert-only: para alterar ou apagar algo existente, ele instrui o usuário, não executa. Quando estoura o timeout, mostra o SQL e o log em vez de inventar uma explicação.
O princípio, que vale para qualquer produto de dados com IA hoje: linguagem natural derruba a barreira de sintaxe, não a de autorização. Se as duas caem juntas, o que foi construído não é autoatendimento, é vazamento com interface de chat.
Por que eu acredito nisso, e o que isso me ensinou
Nada acima foi desenhado no quadro branco antes. Cada bloco veio de um problema encontrado, quase sempre num lugar que já parecia resolvido.
O caso que resume: enquanto integrava a irondome, minha biblioteca de permissões, encontrei uma opção chamada defaultDeny, documentada no README, tipada na assinatura, com padrão declarado, e nunca implementada. O motor sempre negava quando nenhuma policy dava match, então configurar o contrário não fazia nada, em silêncio. O comportamento correto acontecia por coincidência, não por design.
É a assinatura de tudo que eu achei nessa auditoria, e desconfio que seja a assinatura da segurança de dados na maioria das empresas. Funciona porque a pessoa que sabe SQL é de confiança. Porque o relatório sensível está numa pasta que ninguém abriu. Porque quem tem a credencial de produção usa com cuidado. Nada disso é falso. Tudo isso é acidental.
Enquanto o modelo é acidental, ampliar acesso é insustentável, porque ampliar acesso significa exatamente aumentar o número de tentativas. Aí a empresa faz a única coisa que sobra: coloca um humano no meio de cada pedido e chama isso de governança. Não é governança. É lentidão usada como política de segurança, porque não existe fronteira em que se possa confiar.
Construir a fronteira dá trabalho e o trabalho é chato. É exatamente por isso que ele vira produto: é a parte que ninguém quer refazer em casa. A visualização em si, que todo mundo acha que é o produto, é a parte fácil.
O teste que eu passei a fazer
Se eu liberar SQL para todo mundo amanhã, o que quebra?
A lista que sai dessa pergunta é o seu modelo de segurança. Se ela vier vazia, a pergunta ainda não foi feita direito.