A Datadog utilizou os modelos Claude da Anthropic e a ferramenta Cursor para migrar um sistema crítico de produção — o Stream Router — de um modelo de chave-valor (KV) baseado em FoundationDB para PostgreSQL. A operação, que antes levava até 45 minutos, agora é concluída em cerca de 1 segundo.
- A Datadog migrou o Stream Router de FoundationDB para PostgreSQL com ajuda de IA (Claude + Cursor) em um processo test-driven.
- Tempo de operação caiu de 45 minutos para 1 segundo; latência de centenas de ms para poucos ms.
- Armazenamento 40x menor, custos de banco reduzidos em 90%.
- IA gerou código corretamente, mas otimizações finas (batching, CTEs) exigiram intervenção humana.
- Sucesso dependeu de modularidade, testes abrangentes e infraestrutura paralela com validação contínua.
Contexto: Os Limites do Modelo KV no Stream Router
O Stream Router é uma API que gerencia roteamento no pipeline de métricas da Datadog. Originalmente implementado como um sistema eventualmente consistente usando um modelo chave-valor (KV) no FoundationDB, o sistema começou a enfrentar limites severos à medida que a tabela de roteamento crescia. As operações mais pesadas exigiam milhares de viagens de ida e volta ao banco, resultando em até 45 minutos de execução.
No modelo KV, o código precisava reconstruir relações entre entidades manualmente, puxando dezenas de milhares de registros para a memória do pod e simulando um banco relacional em processo — lógica que poderia ser substituída por chaves estrangeiras em um sistema relacional.
A Solução: Redesenho do Schema com PostgreSQL
Os engenheiros da Datadog redesenharam cuidadosamente o schema para refletir as relações entre entidades de domínio, permitindo que chaves estrangeiras substituíssem a lógica que antes precisava ser reconstruída no código da aplicação. A escolha por PostgreSQL como backend relacional trouxe suporte nativo a joins, constraints e otimizações de consulta.
Além do PostgreSQL, a equipe também utilizou DuckDB para consultas analíticas, simplificando ainda mais o tratamento de relacionamentos e melhorando a eficiência das queries.
Abordagem Test-Driven com IA
Para migrar o código existente para o novo schema, a equipe recorreu ao Claude (Anthropic) e ao Cursor, em um processo sistemático e orientado a testes. O fluxo era simples: para cada método, fornecia-se a implementação antiga, o novo schema e um teste que falhava; o Claude gerava uma primeira versão do código; e o teste servia como critério de aprovação.
Três fatores foram essenciais para o sucesso: modularidade do código, suíte de testes abrangente e infraestrutura paralela com um serviço validador que comparava continuamente as respostas das duas versões.
A migração ocorreu em três fases: descrição de intenção, correção de testes com prompts focados e implantação blue/green com comparação contínua.
- Modularidade: o novo Stream Router implementava a mesma API sobre PostgreSQL sem exigir alterações em outros componentes.
- Testes abrangentes: cada mudança era validada por testes automatizados.
- Infraestrutura paralela: duas instâncias rodavam lado a lado, com validação contínua.
Resultados: Ganhos de Performance e Redução de Custos
Os ganhos foram expressivos, como mostra a tabela abaixo. Tempo de operação caiu de até 45 minutos para cerca de 1 segundo. A latência foi reduzida de centenas de milissegundos para poucos milissegundos. O armazenamento tornou-se 40 vezes menor, e os custos com banco de dados foram reduzidos em 90%. CPU e memória também apresentaram redução significativa.
Lições Aprendidas e Limitações
Apesar do sucesso, a abordagem não foi perfeita. Wakim apontou que prompts de alto nível tiveram eficácia limitada; o Claude gerava consultas corretas, mas subótimas — otimizações como batching, UNNEST e CTEs exigiram intervenção humana. Após ver o padrão, o modelo conseguia replicá-lo, mas não o descobria sozinho.
Outro problema foi o alto consumo de tokens, alimentado por dumps completos de saída de testes e pelo loop iterativo. Essas lições mostram que a IA é uma ferramenta poderosa, mas ainda depende de supervisão humana para refinamentos.
Conclusão
A experiência da Datadog demonstra que a combinação de IA generativa com uma forte cultura de testes pode acelerar significativamente migrações complexas. A chave não está na IA em si, mas na qualidade dos testes e na modularidade do sistema, que permitem validar cada mudança de forma confiável. Para profissionais de TI brasileiros, o case reforça a importância de investir em testes automatizados e em arquiteturas que facilitem a substituição de componentes.
| Métrica | Antes (FoundationDB) | Depois (PostgreSQL) |
|---|---|---|
| Tempo de operação | Até 45 minutos | ~1 segundo |
| Latência | Centenas de ms | Poucos ms |
| Armazenamento | Linha de base | 40x menor |
| Custo de banco | Linha de base | Redução de 90% |
| CPU e memória | Alto | Reduzido significativamente |
Arraste para o lado para ver toda a tabela.
Perguntas Frequentes (FAQ)
Quais foram os principais desafios da migração na Datadog?
O principal desafio foi o limite de transações do FoundationDB, que causava operações de até 45 minutos. Além disso, o modelo KV exigia lógica manual para reconstruir relações entre entidades, algo que um banco relacional resolveria com chaves estrangeiras.
Como a IA foi utilizada exatamente no processo?
A equipe usou Claude e Cursor em um fluxo test-driven: para cada método, fornecia-se a implementação antiga, o novo schema e um teste falhando. O Claude gerava o código, e o teste aprovava ou reprovava a mudança.
Quanto tempo levou a migração completa?
O artigo não especifica a duração total, mas o processo foi dividido em três fases: descrição de intenção, correção de testes e implantação blue/green, realizada com duas versões rodando em paralelo.
A abordagem pode ser replicada em outros projetos?
Sim, desde que o projeto tenha forte modularidade, uma suíte de testes abrangente e infraestrutura para executar versões em paralelo. A IA acelera a geração de código, mas a validação depende dos testes.