Por que não rodar migrations SQL em testes, e como isso dobrou a velocidade da suite

O artigo do CEVIU de 1º de junho sobre o branching de bancos de dados no Lakebase da Databricks já apontava para o cerne do problema: 56% dos DBAs ainda gastam horas provisionando ambientes de teste. A solução descrita agora não é só um 'trick' para Go, é a aplicação prática do conceito de database-as-code em escala de desenvolvimento, com duas camadas técnicas críticas que o artigo-fonte detalha bem: primeiro, o uso do backup API do SQLite (não cp) para lidar com WAL, SHM e journal files; segundo, a geração de golden databases por hash SHA256 das migrations, não por timestamp ou versão, isso evita falhas silenciosas quando múltiplas branches contêm scripts conflitantes.

A abordagem elimina o custo de locking sequencial em SQLite (que bloqueia tabelas inteiras durante cada migration), um gargalo que os perfis mostraram ser o principal causador de lentidão real, não o I/O em si, mas a contenção de schema changes. E, diferentemente do que se vê em soluções como o pgdbtemplate (Go, 2025), aqui não há dependência de template pré-construído nem manutenção manual: o golden file é gerado sob demanda, atômico via os.Rename, e isolado por processo, sem lock file, sem race condition funcional.

Em abril, a cobertura CEVIU focou em execução seletiva (Stripe) e caching interval-aware (Netflix), estratégias que reduzem *quantos* testes ou queries rodam. Agora, a mudança é mais profunda: reduz *o que cada teste precisa fazer antes de rodar*. Não é otimização de pipeline, mas de setup. O artigo-fonte confirma que o protótipo inicial com cópia estática de SQLite rendeu 7x, mas a versão final, com hashing dinâmico, backup API e suporte a concorrência, entrega 2.2x na prática. Isso mostra maturação: trocou-se velocidade teórica por robustez operacional, mantendo ganho real sem comprometer correção.

Testes que demoram mais de 3 minutos travam o fluxo de desenvolvedor. Um ganho de 2.2x não é só sobre CI mais rápida, é sobre reduzir o tempo entre escrever código e ver feedback, o que impacta diretamente a qualidade das decisões arquitetônicas. Em monorepos Go com múltiplos serviços (como o citado no artigo), essa técnica também melhora a DX ao eliminar flakiness causada por transações aninhadas ou estado compartilhado entre testes. E, ao usar testing.Testing() como guard, ela evita riscos de produção, algo que o branching do Lakebase da Databricks resolve em outro nível, mas com custo de infraestrutura maior.