Migrations não documentam decisões de banco

Migrations dizem o que mudou.
Quase nunca dizem por que mudou.

Depois de alguns meses, o histórico vira uma sequência de alterações
sem contexto, sem intenção e sem visão do todo.
Entender o schema atual passa a exigir ler dezenas de migrations
e reconstruir mentalmente decisões que nunca foram registradas.

Isso não é um problema da ferramenta de migration,
é de expectativa: migrations não foram feitas para documentar design.

Para tentar tornar isso mais concreto, montei um repositório simples
mostrando um fluxo diferente:

• um modelo único como fonte da verdade
• SQL gerado a partir dele
• docker-compose funcional
• diagrama e decisões de modelagem versionados junto

Repo (exemplo técnico):
https://github.com/ThiagoRosa21/schema-versioning-demo

A ideia não é substituir migrations,
mas separar claramente:

• migrations para execução
• modelo e documentação para entendimento

Como vocês hoje entendem o “porquê” do schema atual nos projetos de vocês?