Imagina que estás construyendo una aplicación de citas y alcanzas un hito importante un millón de usuarios. En los primeros días usaste una columna simple llamada kids que almacenaba un texto como yes- they live with me o no. Con el crecimiento del producto el equipo pide datos más estructurados: necesitan saber si el usuario tiene hijos, si viven en casa y cuál es su deseo sobre tener hijos. Pasar de una cadena a un objeto anidado es más complejo de lo que parece porque el código nuevo puede romperse al leer datos antiguos.
Para evitar errores y tiempos de inactividad debes gestionar el estado intermedio donde coexisten datos antiguos y código nuevo. La solución probada es el patrón Expand and Contract.
Fase 1 Expand o puente de seguridad
No modifiques la columna existente. Añade una nueva columna JSONB para el nuevo formato, por ejemplo kids_v2 con valor por defecto objeto vacío. Actualiza la aplicación para escribir en ambas columnas cada vez que un usuario actualice su perfil. Esta doble escritura garantiza compatibilidad hacia atrás mientras se introduce el nuevo modelo. Mapea la cadena antigua a los campos nuevos de forma clara: hasKids será verdadero cuando la cadena comience con yes, liveAtHome verdadero si la cadena indica que viven con el usuario, y establece wantsKids a un valor por defecto como Not Decided.
Fase 2 Migración o backfill
Tienes millones de filas con kids_v2 vacío. No hagas una actualización masiva en una sola transacción porque bloquearás la tabla. Haz la migración en lotes pequeños desde un script de backend. Por ejemplo procesa 5000 filas por lote, actualizando kids_v2 a un objeto JSON construido a partir de la columna antigua usando expresiones condicionales para inferir hasKids y liveAtHome, y deja un valor por defecto para wantsKids. Entre lotes deja una pausa corta para no saturar la base de datos y permitir que el resto del tráfico siga respondiendo con normalidad.
Fase 3 Contract o limpieza final
Cuando todos los registros tengan kids_v2 válido, cambia el API para leer solo de kids_v2. Supervisa los logs en busca de errores de propiedades indefinidas durante varios días. Si no aparecen errores, elimina la columna antigua y quita la lógica de doble escritura. Con esto completas la transición sin romper la experiencia de usuario ni la integridad de los datos.
Este enfoque no solo evita caídas; protege la integridad de la información y permite realizar migraciones seguras en entornos con muchos usuarios activos. Saltar de un tipo a otro sin una estrategia en fases es una receta para errores en producción.
En Q2BSTUDIO somos especialistas en llevar a cabo migraciones y desarrollos complejos sin impacto en el servicio. Ofrecemos desarrollo de aplicaciones a medida y software a medida con enfoque en calidad y escalabilidad; puedes conocer nuestro enfoque en desarrollo de aplicaciones a medida. Además ayudamos a arquitecturas cloud y a diseñar procesos seguros en plataformas gestionadas mediante servicios cloud aws y azure.
También trabajamos en inteligencia artificial para empresas, agentes IA, servicios inteligencia de negocio y power bi, y ciberseguridad y pentesting para proteger tus datos sensibles. Si necesitas soporte en automatización, integración con servicios cloud o consultoría para ia para empresas, en Q2BSTUDIO combinamos experiencia técnica y buenas prácticas para ejecutar migraciones sin riesgos.
Quieres compartir tu peor historia de migración o necesitas asesoría para cambiar tipos de columnas en PostgreSQL sin afectar a tus usuarios existentes Contacta con nosotros y te ayudamos a diseñar la estrategia adecuada.