Migrações: Mudando o Schema com Segurança

Seu schema vai mudar — você vai adicionar uma coluna, renomear uma tabela, adicionar um índice. Pense nisso como edições rastreadas de um documento compartilhado: toda mudança é registrada em ordem, para que a cópia de todo mundo possa ser atualizada da mesma forma. Uma migração é um script versionado e repetível que descreve uma dessas mudanças. Migrações importam porque o schema no seu laptop, no laptop do seu colega de equipe e em produção precisam permanecer idênticos.

As regras que mantêm migrações seguras:

• Nunca edite o banco de dados manualmente em produção. Escreva uma migração.
• Migrações avançam. Cada uma é um arquivo novo; você não reescreve as antigas que já rodaram.
• Faça mudanças destrutivas com cuidado. Descartar uma coluna ou tabela apaga dados permanentemente. Tenha um backup primeiro.
• Mudanças aditivas são as mais seguras. Adicionar uma coluna anulável raramente quebra alguma coisa; renomear ou remover uma pode quebrar código em execução.

Migrações formam uma cadeia ordenada: cada uma é um passo numerado que move cada cópia do banco de dados de um estado conhecido para o próximo, para que seu laptop, o de um colega de equipe e a produção acabem todos idênticos:

   BD vazio
      │
      ▼
  ┌────────────┐   ┌────────────┐   ┌────────────┐   ┌────────────┐
  │ 001_init   │ ▶ │ 002_add    │ ▶ │ 003_index  │ ▶ │ 004_bio    │
  │ users      │   │ posts      │   │ on author  │   │ column     │
  └────────────┘   └────────────┘   └────────────┘   └────────────┘
   aplicar em ordem ────────────────────────────────────────▶ atual
   nunca edite um passo que já rodou — adicione um NOVO

Ferramentas como Prisma, Drizzle ou migrações do Rails geram e rastreiam isso para você. Deixe que elas façam.

Uma migração tem duas metades: a mudança a aplicar (up) e como desfazê-la (down). Uma ferramenta confiável gera as duas, para que um deploy ruim possa voltar atrás de forma limpa:

-- up: adiciona uma bio opcional, seguro para aplicar ao vivo
ALTER TABLE users ADD COLUMN bio TEXT;

-- down: reverte
ALTER TABLE users DROP COLUMN bio;

As migrações genuinamente perigosas são renomeações e mudanças de tipo, porque o código antigo e o novo schema discordam brevemente. O padrão profissional é dividi-las em passos aditivos: adicione a nova coluna, preencha os dados retroativamente, mude o código para lê-la, e só descarte a coluna antiga em um deploy posterior, uma vez que nada mais a referencie. Parece lento, mas é a diferença entre um lançamento tranquilo e um pico de erros de página 500 para cada usuário no meio do deploy.