Cambiar una columna y desplegar la aplicación al mismo tiempo crea un instante en el que ambas versiones deben coincidir. En un despliegue gradual, réplicas antiguas y nuevas conviven; una migración compatible permite que las dos funcionen durante la transición.
La secuencia expandir, migrar y contraer divide un cambio irreversible en pasos observables. No es una función del motor: es una estrategia de entrega que usa operaciones concretas del esquema y compatibilidad temporal en la aplicación.
Ejemplo: separar un nombre
Partimos de customers.full_name y queremos given_name y family_name.
1. Expandir
Añade las columnas nuevas como opcionales. No elimines ni cambies todavía la columna anterior. PostgreSQL permite añadir columnas con ALTER TABLE, pero el coste y los bloqueos dependen de versión, valor por defecto, tamaño y operación concreta: prueba con una copia representativa.
Despliega una versión capaz de leer el campo antiguo y escribir ambos formatos. Añade métricas para detectar divergencias.
2. Migrar datos
Ejecuta el backfill en lotes pequeños, reanudables e idempotentes. Conserva un cursor y limita carga. La separación automática de nombres puede ser ambigua; define qué casos requieren revisión en lugar de inventar una regla universal.
Comprueba por lote:
- filas candidatas, actualizadas y fallidas;
- nulos y excepciones;
- equivalencia de la representación reconstruida;
- latencia y bloqueos;
- posibilidad de repetir sin duplicar efectos.
3. Cambiar lecturas
Cuando escrituras y backfill estén completos, despliega la lectura desde columnas nuevas. Mantén observación y una ruta de reversión que todavía pueda usar full_name.
4. Contraer
Solo después de confirmar que ningún consumidor usa el campo antiguo, deja de escribirlo, aplica restricciones nuevas y elimina la columna en otra versión. La eliminación es un cambio distinto y merece su propio plan.
Compatibilidad por versión
| Versión | Lee | Escribe |
|---|---|---|
| antigua | full_name |
full_name |
| transición | nuevo con fallback antiguo | antiguo y nuevo |
| nueva | nuevo | nuevo y, temporalmente, antiguo |
| final | nuevo | nuevo |
Evita dobles escrituras indefinidas: aumenta estados posibles y puede ocultar conflictos. Define propietario, fecha de retirada y condición medible.
Riesgos operativos
Las modificaciones de esquema pueden bloquear, reescribir tablas o crecer el log de transacciones. Ensaya volumen, duración, réplica y rollback. No combines en una sola operación añadir, rellenar, imponer NOT NULL y borrar lo anterior.
Para cambios entre bases o infraestructuras, AWS recomienda sincronización final, pruebas y criterios claros de corte y retorno. La misma disciplina sirve a una tabla: congela decisiones irreversibles hasta tener evidencia.
Lista de aceptación
- aplicación anterior y nueva funcionan con el esquema expandido;
- backfill tiene progreso, pausa y reanudación;
- restricciones se aplican después de limpiar datos;
- consumidores y trabajos externos están inventariados;
- métricas confirman que el campo antiguo ya no se usa;
- el rollback está probado antes de contraer.
Separa estos cambios entre entornos de datos y revisa el plan como cualquier cambio de infraestructura como código. La continuidad proviene de mantener compatibilidad durante el tránsito, no de ejecutar más rápido una migración monolítica.