Quem desenvolve em Django sabe que o ORM da ferramenta é um dos seus maiores trunfos. O sistema de migrations rastreia cada alteração nos seus modelos e sincroniza isso com o banco de dados de forma quase mágica. Mas o que acontece quando o seu projeto entra no terceiro, quarto ou quinto ano de vida e um único app acumula mais de 200 arquivos de migração?

Para o gestor técnico, esse acúmulo deixa de ser apenas “histórico” e passa a ser um problema de performance na esteira de desenvolvimento. É aqui que entra o Migration Squashing.

O que é o Squashing e o que muda na prática?

De forma direta, o Squashing (ou “esmagamento”) é o processo de reduzir um conjunto longo de migrações em um ou poucos arquivos otimizados.

Se na migração 0001 você criou uma tabela, na 0015 adicionou uma coluna, e na 0030 excluiu essa mesma coluna, o Django é inteligente o suficiente para analisar esse histórico e gerar um único arquivo substituto que simplesmente cria a tabela final, ignorando as idas e vindas do passado.

O que muda no dia a dia da engenharia:

  1. CI/CD muito mais rápido: Ferramentas de integração contínua rodam todas as migrações do zero para criar bancos de dados de teste. Reduzir 300 migrações para 5 poupa minutos preciosos em cada commit, reduzindo a fila de deploys e custos de servidor.
  2. Onboarding de novos Devs: Levantar o ambiente local pela primeira vez deixa de ser uma pausa para o café de 15 minutos e volta a ser um processo de segundos.
  3. Organização da Base de Código: Facilita a vida do Tech Lead na hora de debugar como uma tabela foi estruturada, sem precisar navegar por dezenas de arquivos legados.

Faz sentido começar um projeto já usando?

Não. O squashing é uma ferramenta de manutenção para sistemas maduros, não para novos projetos.

No início de um projeto ou durante o desenvolvimento de uma nova feature, você quer ter a granularidade do histórico. Se você cometer um erro, é fácil reverter (fazer o rollback) de uma migração pequena. O momento certo de pensar em squash é quando o seu aplicativo atinge estabilidade em produção e o peso das dezenas de arquivos começa a atrasar os pipelines de teste.

Sistemas em produção: Vale a pena ajustar? Tem como?

Sim, vale muito a pena, mas exige estratégia. Refatorar o histórico de um banco de dados de um sistema em produção rodando a todo vapor dá calafrios em qualquer gestor técnico, mas o Django foi desenhado para permitir isso de forma segura, usando um processo de transição.

Não é simplesmente apagar o passado; é criar uma ponte. Veja como funciona a mecânica técnica para implementar:

1. Gerando o arquivo Squashed

Você utiliza o comando nativo do manage.py, informando o aplicativo e até qual migração você quer comprimir:

O Django criará um novo arquivo (ex: 0001_squashed_0050.py).

2. A Mágica do atributo replaces

Se você abrir esse novo arquivo, verá que ele contém uma lista chamada replaces. Essa é a trava de segurança. Ela diz ao Django: “Se o banco de dados já aplicou as migrações de 0001 a 0050, ignore este arquivo. Se for um banco novo, rode este arquivo e marque todas as 50 como concluídas.”

Nesta fase, você não apaga nada. Você envia para produção o arquivo novo convivendo com os antigos.

3. A Limpeza Definitiva

Depois de fazer o deploy e garantir que todos os seus ambientes (Desenvolvimento, Staging/Homologação e Produção) passaram por essa atualização e estão com as migrações em dia, você pode finalmente fazer a faxina:

  • Exclua os arquivos de 0001 a 0050.
  • Remova o atributo replaces do arquivo squashed.
  • Faça um novo commit. Seu sistema agora está leve e com o histórico limpo.

Onde a teoria esbarra na prática (E como resolvemos isso)

A documentação faz parecer simples, mas na vida real de sistemas complexos, o comando squashmigrations frequentemente falha. Por quê?

  • Dependências Circulares: O App “Pedidos” depende de uma migração do App “Clientes”, que por sua vez depende de uma do App “Pedidos”. O squashing trava.
  • Operações Manuais (RunPython / RunSQL): Se o seu time escreveu scripts customizados dentro das migrações para alterar dados (não apenas esquemas), o Django não consegue esmagar isso automaticamente com segurança.

Para resolver isso, é necessário intervir manualmente nos arquivos gerados, extraindo as operações de dados RunPython ou ajustando a ordem do atributo dependencies. É um trabalho cirúrgico de engenharia de software.

A Smartflow Sistemas tem profunda experiência na arquitetura e otimização de sistemas Django. Quando um monolito ou microsserviço começa a gargalar por débito técnico, nós atuamos direto na raiz. Mapeamos as dependências do ORM, resolvemos os conflitos circulares e aplicamos o squashing com garantia de zero-downtime para a operação do cliente. A tecnologia precisa acelerar o seu negócio, e não deixar sua equipe técnica presa no passado.