Migraciones de DynamoDB sin tiempo de inactividad

Si vienes de SQL, una migración es un ALTER TABLE que bloquea la tabla mientras reescribe cada fila. DynamoDB no tiene esquema que alterar — los items no tienen esquema, así que añadir un atributo o un nuevo tipo de entidad es gratis.

La parte difícil es el patrón de acceso que los nuevos datos tienen que servir, y remodelar los datos en vivo para servirlo sin una reescritura que detenga el mundo.

¿Cómo se migra una tabla de DynamoDB sin tiempo de inactividad?

DynamoDB no tiene ALTER TABLE, por lo que las migraciones nunca bloquean la tabla. Añades atributos, una nueva forma de clave o un nuevo GSI online con UpdateTable, y luego remodelas los datos en vivo de forma incremental: haz backfill de los items antiguos de forma perezosa en la lectura o con un barrido controlado, y usa dual-write en ambos formatos durante la transición. No hay un corte de día señalado.

• No hay ALTER TABLE. Los items no tienen esquema. Una "migración" significa añadir atributos, una nueva forma de clave o un nuevo índice — nunca reescribir un conjunto fijo de columnas.
• Las escrituras nuevas son fáciles; los items antiguos son el problema. Las filas existentes no llevan los nuevos atributos, así que cualquier índice o consulta nueva los omite en silencio hasta que haces backfill.
• Añade índices online, haz backfill de forma perezosa. UpdateTable construye un GSI sobre una tabla en vivo; haz backfill de los items antiguos en la lectura (perezoso) o con un barrido controlado — nunca un corte de día señalado.
• Dual-write durante la transición. Mientras ambas formas coexisten, escribe el formato antiguo y el nuevo juntos para que ninguna ruta de lectura se quede obsoleta.

Plantéalo como un patrón de acceso, no una columna

Supón que gestionas un producto SaaS de espacios de trabajo en una tabla. Los items usan PK = "WS#<id>" y SK sobrecargado por entidad:

Ahora producto quiere comentarios en los documentos, más una nueva lectura: "lista cada comentario que un miembro escribió en todo el espacio de trabajo, el más nuevo primero." Esa última cláusula es la migración. Un nuevo tipo de entidad por sí solo es trivial; servir una consulta que las claves actuales no pueden responder es el trabajo.

Añade primero el nuevo tipo de entidad

Los comentarios no son más que items nuevos en la misma partición — sin ceremonia de migración, sin tabla nueva:

Un Query sobre PK = "WS#a91" con SK begins_with "DOC#2026-04-01#x7#CMT#" ya lista los comentarios de un documento. Los documentos existentes quedan intactos. Esta mitad se despliega el primer día — ver item collections y claves sobrecargadas para entender por qué la misma partición contiene ambos.

La nueva consulta necesita un GSI

"Todos los comentarios de un miembro, el más nuevo primero" no puede servirlo la tabla base — memberId no es ni la PK ni un prefijo de SK. Eso es un nuevo índice, y elegirlo correctamente es su propia decisión: ver GSI vs LSI (un LSI debe existir en la creación de la tabla, así que para una migración en una tabla en vivo un GSI es tu única opción).

Añade un GSI1 genérico y escribe los nuevos atributos en los nuevos items de comentario:

Query GSI1 WHERE GSI1PK = "MEMBER#u44" con ScanIndexForward = false da los comentarios más nuevos primero por miembro.

Construye el índice online

UpdateTable añade un GSI a una tabla en vivo sin tiempo de inactividad. DynamoDB hace backfill de los items existentes en el índice en segundo plano; el índice informa CREATING/backfilling hasta que termina, luego pasa a ACTIVE (Gestión de GSI).

Dos trampas aquí. Primero, AWS advierte que añadir un GSI puede throttlear las escrituras de la tabla base si la nueva clave se distribuye de forma desigual — añádelo en una ventana de poco tráfico y vigila CloudWatch. Segundo, el índice es eventualmente consistente incluso después de pasar a ACTIVE; una escritura puede no ser visible en el GSI durante un momento. Ver por qué los GSI son eventualmente consistentes.

Haz backfill de los items antiguos

El GSI solo indexa items que tienen GSI1PK/GSI1SK. Tus comentarios previos a la migración — escritos antes de que el atributo existiera — nunca aparecen, ni siquiera tras completarse el backfill. El backfill online del GSI copia los items existentes, pero no puede inventar atributos que no están en ellos. Tienes que añadir los valores.

Dos estrategias:

Para el barrido, pagina con Scan, y por cada comentario antiguo añade los atributos del índice con un UpdateItem condicional para no pisar nunca una escritura concurrente.

La condición protege sobre que el atributo no exista ya. Construye y copia el ConditionExpression y UpdateExpression exactos con el DynamoDB Expression Builder en lugar de teclear a mano attribute_not_exists(GSI1PK).

Dual-write durante la transición

Hasta que cada item antiguo lleve los nuevos atributos, dos formas coexisten. La ruta de escritura debe poblar el nuevo formato en cada escritura — comentarios nuevos y cualquier actualización de uno antiguo — para que la brecha solo se encoja.

Elige una condición de fin de backfill que puedas verificar: el barrido paginó toda la tabla, o la ruta perezosa ha funcionado el tiempo suficiente como para que los items sin convertir estén obsoletos por diseño. Solo entonces retiras la ruta de lectura antigua. Saltarte esto es como una migración "se completa" mientras una fracción de las consultas devuelve resultados cortos en silencio.

Trampas

• Añadir el atributo ≠ backfilleado. Un nuevo GSI empieza vacío para los items antiguos. Verifica la cobertura antes de confiar en la consulta.
• Cambiar una clave en su sitio no es una migración — es una reescritura. No puedes mutar la PK/SK de un item; escribes un item nuevo bajo la nueva clave y borras el antiguo. Planifícalo como copiar-luego-borrar, con dual-read en medio.
• Sin corte transaccional. No hay un momento en el que toda la tabla cambie. Diseña cada paso para que sea seguro mientras ambas formas están en vivo.

Próximos pasos

Revisa las nuevas claves y colecciones sobrecargadas en single-table design, y confirma que el backfill está completo paginando la tabla en vivo. Prueba DynoTable para navegar tu tabla, detectar items sin backfillear y ejecutar las actualizaciones condicionales contra tus propios datos.