Alembic (o el equivalente en otros stacks: Flyway, Prisma Migrate, Django migrations) es la respuesta por default a "¿cómo versiono mi esquema de base de datos?", y con buena razón: automatiza el historial de cambios, permite autogenerate a partir de los modelos, y da una ruta de upgrade/downgrade reproducible. Pero "es la opción por default" no significa "es la opción correcta en todos los proyectos". He mantenido proyectos con Alembic y proyectos con simples scripts de migración manuales, y la elección correcta depende más del tamaño del equipo y la frecuencia de cambios que de cuál herramienta es más popular.
Lo que un framework de migraciones te da
Con Alembic, cada cambio de esquema es una revisión versionada con un identificador único, encadenada a la anterior. La tabla alembic_version en la base de datos registra en qué revisión está cada entorno, así que alembic upgrade head sabe exactamente qué falta aplicar. El autogenerate compara los modelos de SQLAlchemy contra el estado real de la base y propone el diff automáticamente — muy útil cuando el esquema cambia seguido y hay varios desarrolladores tocando modelos en paralelo.
El costo oculto que no se ve en el tutorial
Ese mismo encadenamiento de revisiones que da orden tiene un costo de mantenimiento: si dos ramas de Git agregan migraciones en paralelo, terminas con "multiple heads" y hay que fusionarlas manualmente antes de poder aplicar cualquiera. Para un equipo grande con varios entornos (dev/staging/prod) que necesitan mantenerse sincronizados automáticamente, ese costo vale la pena. Para un proyecto con uno o dos desarrolladores y cambios de esquema poco frecuentes pero grandes (agregar un módulo completo cada varias semanas, no una columna cada día), ese mismo costo es pura fricción: aprender el flujo de revisiones, resolver heads múltiples, y mantener un directorio de migraciones que crece con revisiones que ya nadie necesita revisar individualmente.
El caso real: tres scripts, tres ejecuciones, cero fricción
En un sistema de inventario con QR/barras que crecía por fases (una fase agregaba órdenes de compra, otra agregaba requisiciones, otra agregaba auditoría), usé tres scripts — migrate_v2.py, migrate_v3.py, migrate_v4.py — cada uno pensado para ejecutarse una sola vez, en orden, directamente contra la base de datos en producción. Cada script es una lista de sentencias ALTER TABLE ... ADD COLUMN IF NOT EXISTS o CREATE TABLE IF NOT EXISTS, sin ningún framework encima. No hay tabla de versiones, no hay downgrade, no hay autogenerate — solo un script de Python que se corre con python scripts/migrate_v3.py cuando toca desplegar esa fase, y ya.
La regla que hace esto seguro: idempotencia
La razón por la que este enfoque no es simplemente "más arriesgado" es que cada script está escrito para poder correrse dos veces sin romper nada. ADD COLUMN IF NOT EXISTS no falla si la columna ya existe; un INSERT de datos semilla se protege con un SELECT previo que verifica si el registro ya está ahí. Esa idempotencia es la red de seguridad que reemplaza al versionado formal: si un despliegue se repite por accidente, o si alguien corre el script equivocado por error, el peor caso es que no pase nada — no que se dupliquen datos o se rompa una restricción.
Dónde Alembic sigue siendo la opción correcta
Este enfoque manual deja de tener sentido en cuanto aparece cualquiera de estas condiciones: varios desarrolladores modificando el esquema en paralelo con frecuencia, necesidad real de poder revertir un cambio (downgrade) en vez de solo avanzar, o múltiples entornos que deben poder verificar automáticamente "qué migraciones me faltan" sin que alguien lo recuerde de memoria. En un proyecto de encuestas internas que mantengo con Alembic, el equipo es pequeño pero los cambios de esquema son más frecuentes y el autogenerate ahorra más tiempo del que cuesta mantener el directorio de revisiones.
Conclusión
La pregunta correcta no es "¿cuál es la herramienta más profesional?" sino "¿qué tan seguido cambia mi esquema, y cuánta gente lo toca en paralelo?". Un framework de migraciones resuelve un problema de coordinación entre varias personas y entornos; si ese problema no existe todavía en tu proyecto, estás pagando su complejidad sin recibir el beneficio. Un script idempotente, ejecutado una vez y documentado, puede ser la opción más simple y menos propensa a errores — hasta que el proyecto crezca lo suficiente para que valga la pena migrar a algo más formal.