Cómo evitar perder datos al migrar columnas

Contenido del curso

Fundamentos y Primer CRUD

Base de Datos y Persistencia con TypeORM

Autenticación y Autorización

Tu API Completa

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0020:45

Cómo evitar perder datos al migrar columnas

Curso de Backend con NestJS

Clase 23 de 35

Clase 23 / 35

Recursos

Cuando trabajas con migraciones en TypeORM y ya tienes datos en producción, cualquier cambio en una columna puede borrar información valiosa. Aquí aprenderás a modificar entidades, agregar columnas y ajustar restricciones sin perder los datos de tus usuarios.

¿Cómo agregar columnas nuevas sin romper datos existentes?

Antes de tocar cualquier esquema, conviene tener datos reales en la base. Crea un par de usuarios, categorías y artículos desde tu API para simular un entorno productivo y ver con claridad qué pasa cuando aplicas una migración sobre tablas que ya tienen información.

La primera regla es sencilla: si una columna no existía antes, debe declararse como nullable: true. Si intentas crearla como obligatoria, la migración fallará porque no hay forma de llenar los registros antiguos. Por ejemplo, al agregar description con un tamaño de 800 caracteres a la entidad Category, debes marcarla como nula. Lo mismo aplica para una nueva columna cover_image en categorías.

¿Cuándo debo usar nullable: true en una migración? Siempre que agregues una columna a una tabla que ya tiene registros. Si la haces obligatoria, no podrás llenar las filas antiguas y la migración se romperá.

¿Y si necesito que la columna sea obligatoria?

El flujo correcto es en tres pasos: primero creas la columna como nula, luego ejecutas un script para poblar los registros antiguos con valores reales, y por último corres una segunda migración que cambie la restricción a not null. Este trabajo suele coordinarse con el equipo de data o ingeniería para automatizar el script de poblamiento.

¿Por qué cambiar el tamaño de un varchar puede borrar tus datos?

Aquí viene la parte delicada. Si en Post tienes una columna cover_image con tamaño 255 y decides aumentarla a 800, parecería un cambio inofensivo. Pero al ejecutar migration:generate, TypeORM genera dos instrucciones peligrosas: un DROP COLUMN seguido de un ADD COLUMN con la nueva restricción.

El resultado: todas las imágenes que tus usuarios ya habían cargado desaparecen. La estructura queda correcta, pero los datos se pierden. Y aunque puedes hacer un revert para volver al esquema anterior, los datos ya no se recuperan.

¿Qué hace migration:generate cuando cambio un varchar? En lugar de alterar la columna, la elimina y la crea de nuevo con el tamaño actualizado. Eso borra toda la información previa de esa columna.

Por eso es fundamental abrir el archivo de migración generado y revisar instrucción por instrucción antes de ejecutarlo en producción. Si ves un dropColumn seguido de un addColumn sobre una tabla con datos, detente.

¿Cómo escribir una migración manual con alter column?

La solución es generar una migración manual usando el comando migration:create en lugar de migration:generate. La diferencia es clave:

generate lee el data source y deduce los cambios automáticamente comparando entidades contra la base.
create solo te entrega un boilerplate vacío para que tú escribas el SQL.
create no necesita el flag -d porque no consulta la base de datos.

Dentro del archivo manual, reemplazas el dropColumn por una instrucción de alteración directa:

typescript await queryRunner.query( ALTER TABLE post ALTER COLUMN cover_image TYPE varchar(900) );

En el método down, devuelves la columna a su tamaño anterior, en este caso 800, para mantener la reversibilidad. Al ejecutar migration:run, el cambio se aplica sin tocar los datos. Haces refresh en la base y verificas: el límite ahora es 900 y todas las cover_image siguen ahí.

¿Qué comandos conviene tener a la mano?

Estos son los que más vas a usar al trabajar con migraciones en TypeORM:

migration:generate: crea la migración deduciendo cambios desde tus entidades.
migration:create: genera un archivo vacío para escribir SQL manual.
migration:show: lista qué migraciones se han ejecutado y cuáles están pendientes.
migration:run: aplica las migraciones pendientes.
migration:revert: deshace la última migración aplicada, pero no recupera datos.

¿Cuándo revisar manualmente una migración generada?

La respuesta corta: siempre que toques una columna existente. La automatización funciona bien para crear tablas nuevas o agregar columnas, pero falla cuando se trata de modificar restricciones sobre columnas con datos.

Si tu equipo tiene conocimientos de SQL o cuentas con un equipo de data, pídeles que revisen la migración antes de ejecutarla en producción. Un dropColumn mal interpretado sobre una tabla con mil millones de artículos puede convertirse en un incidente serio.

La lección práctica: los datos no son un lujo recuperable. La estructura del esquema sí se puede revertir, pero la información perdida no vuelve. Por eso la disciplina de revisar, ajustar y, cuando sea necesario, escribir migraciones manuales marca la diferencia entre un sistema robusto y uno frágil.

¿Has tenido que rescatar una migración antes de ejecutarla en producción? Cuéntalo en los comentarios.

Osvaldo Frias

Hace un año

No me convence del todo. Pero entiendo que este fue un ejemplo para demostrar lo catastrófico que puede llegar a ser el ejecutar las migraciones sin hacer una revisión del código que nos está generando. En ese sentido me parece valioso.

Creo que valdría la pena mencionar que al llevar esta migración a producción se replicaría el mismo comportamiento y borraríamos todos nuestros datos, aunque ya hayamos hecho el "parche".

Esto me genera una duda, ¿se podría modificar o borrar la migración ya creada con código no deseado?

Johan Corrales

Hace 6 meses

Si vas a cambiar un tipo de dato en una tabla gigante, no uses ALTER COLUMN directamente. El estándar es:

Crear una nueva columna con el nombre cover_image_new.
Migrar los datos en lotes (batches) de la vieja a la nueva.
Renombrar la vieja a cover_image_old y la nueva a cover_image.
Borrar la vieja tras verificar que todo está bien.

Lina María Arango

Hace 4 meses

Esta es la razón por la que el compañero sugiere no hacerlo en entornos de producción: ¿Por qué evitar ALTER COLUMN directo?

Reescritura completa de la tabla. El motor tiene que recorrer cada fila, convertir el valor al nuevo tipo, y reescribirla físicamente en disco. En una tabla con millones de filas, esto puede tomar minutos u horas.
Bloqueo (lock) de la tabla. Mientras dura esa reescritura, en muchos motores (especialmente versiones antiguas de MySQL/MariaDB, o PostgreSQL en ciertos cambios de tipo) la tabla queda bloqueada para escritura, y a veces incluso para lectura. Si esa tabla es de uso constante, tu aplicación completa puede caerse o quedar congelada ese tiempo.
Riesgo de timeout y transacciones largas. Si la operación tarda demasiado, puede chocar con timeouts de conexión, otros procesos esperando el lock, o incluso llenar el log de transacciones.
Difícil de revertir. Si algo sale mal a la mitad del proceso, revertir una alteración de tipo de columna ya aplicada es mucho más complicado que simplemente "deshacer" una migración por lotes.

Fundamentos y Primer CRUD

Crea una API RESTful con NestJS

Instalación del CLI de NestJS y primer proyecto con API

Creación de endpoints dinámicos para consultar usuarios en NestJS

Operaciones CRUD en APIs REST con Postman

Método PUT para actualizar usuarios con ID automático

Manejo de status codes HTTP en NestJS

DTOs y validación automática de datos en APIs con NestJS

Servicios y lógica de negocio en NestJS

Variables de entorno seguras en NestJS

Programación modular en NestJS con UserModule

Base de Datos y Persistencia con TypeORM

Configuración de PostgreSQL con Docker y Docker Compose

Configuración de PostgreSQL con TypeORM en aplicaciones NestJS

Creación de entidades ORM con decoradores en TypeScript

Repository Pattern con TypeORM en NestJS

Relaciones uno a uno entre usuarios y perfiles en PostgreSQL

Actualización de DTOs con mapped types en NestJS para perfil y usuario

Generación automática de módulos CRUD con NestJS y AI

Relación uno a muchos con TypeORM

CRUD de categorías con IA en NestJS

Relaciones many-to-many con TypeORM y validación de arrays

Reutilización de servicios entre módulos en NestJS

Migraciones en TypeORM sin perder datos

Cómo evitar perder datos al migrar columnas

Autenticación y Autorización

Hashing de contraseñas con Bcrypt en NestJS

Excluir campos sensibles con ClassTransformer

Autenticación local con Passport en NestJS

Endpoint de login con Passport en NestJS

Implementación de JSON Web Token para autenticación en NestJS

Rutas protegidas con JWT en NestJS

User ID automático desde JWT en NestJS

Tu API Completa

Autogenera resúmenes e imágenes con OpenAI en NestJS

Documentación automática de APIs con Swagger en NestJS

Preparar tu API NestJS para producción

Desplegar aplicación Node.js a producción con Railway y PostgreSQL

Desarrollo de API REST escalable con NestJS en producción

Cómo evitar perder datos al migrar columnas