Migraciones de base de datos en Bolt sin perder datos

Para cambiar la base de datos de una app de Bolt.new sin sustos, haz cada cambio como una migración SQL escrita, que revisas antes de ejecutar y que queda guardada junto al código, en lugar de pedir arreglos rápidos por el chat o tocar la estructura desde el editor de tablas. Respalda los datos antes, prefiere los cambios que solo agregan, deja para después todo lo que renombre o borre hasta que el código ya no dependa de eso, y revisa la app al terminar. Restaurar una versión anterior en Bolt no deshace los cambios de la base, así que la base necesita su propia red de seguridad.

Aquí verás por qué los cambios improvisados traen problemas, qué cambios son seguros y cuáles no, una rutina paso a paso dentro de Bolt y cómo hacer lo mismo con la CLI de Supabase cuando la app ya tiene usuarios.

¿Por qué es riesgoso editar la base sobre la marcha?

Cuando escribes "agrega un estado a los pedidos", el agente cambia la base en vivo y el código al mismo tiempo. Para un prototipo está bien. Cuando ya hay gente usando la app, aparecen los problemas:

• El código y la base se desfasan. El historial de versiones de Bolt restaura archivos, no tablas, y su documentación lo aclara: volver a una versión anterior no modifica tu base de Bolt ni de Supabase. Si deshaces el código después de un cambio de estructura, la app puede pedir columnas que ya no coinciden.
• No queda registro. Sin un archivo de migración, nadie sabe después por qué existe una columna o a cuál reemplazó.
• El agente puede tomar el atajo. Si le pides "arreglar" una tabla, una IA puede borrarla y crearla de nuevo, y con eso se van sus filas.
• Muchas veces hay una sola base. En muchos proyectos de Bolt la vista previa y el sitio publicado comparten base, así que un error mientras pruebas les pega a clientes reales.

¿Qué es una migración?

Una migración es un archivo SQL que describe un cambio, lleva una marca de tiempo en el nombre y se aplica una sola vez, en orden. Con la CLI de Supabase viven en supabase/migrations/ con nombres como 20261020143000_add_order_status.sql, y la base lleva la cuenta de cuáles ya se aplicaron. Abre la vista de código y fíjate si tu proyecto ya tiene esa carpeta; si el agente estuvo escribiendo archivos SQL ahí, son tu historial de cambios hasta hoy.

El valor es simple: cada cambio queda a la vista, se puede revisar, repetir en otra base y guardar en GitHub junto al código que lo necesita.

¿Qué cambios son seguros y cuáles no?

Renombrar sin romper nada

Los cambios riesgosos se hacen por etapas, lo que suele llamarse expandir y contraer:

-- 1. Expandir: agrega la columna nueva junto a la vieja
alter table public.orders add column if not exists status text;

-- 2. Copia los datos existentes
update public.orders set status = state where status is null;

Después cambia el código para que lea y escriba status, publica y comprueba que funciona. Recién en una migración posterior, cuando nada use state, bórrala:

alter table public.orders drop column state;

¿Cómo cambio la base de forma segura en Bolt?

1. Pide primero el SQL, sin ejecutarlo. En modo Plan: Write the SQL migration for adding a status column to orders as a new file in supabase/migrations. Don't run it, and don't drop, rename or recreate any table.
2. Respalda los datos. En la configuración de la base, abre cada tabla afectada, selecciona todas las filas y elige Export (CSV o JSON). Descarga también el proyecto. La documentación de Tables de Bolt explica la exportación.
3. Lee el SQL antes de que corra. Busca drop, truncate, delete sin where, alter ... type y rename. Si aparece alguno que no pediste, frena y pregunta por qué.
4. Aplícalo. Deja que Bolt ejecute la migración o pégala en el editor SQL (Query en la vista Tables).
5. Verifica. Revisa las columnas y algunas filas, abre la pestaña Security para confirmar que cualquier tabla nueva tiene RLS activo y recorre los flujos principales de la app.
6. Marca la versión en el historial, para saber qué código corresponde a esta forma de la base.

Las tablas nuevas merecen un aparte. La documentación de seguridad de Bolt indica que Bolt activa RLS en las tablas que crea, pero las que agregues tú también lo necesitan. Una tabla sin RLS la puede leer y modificar cualquiera que tenga tu clave pública, así que incluye alter table ... enable row level security; y las políticas en la misma migración.

¿Qué cambia cuando la app ya tiene usuarios reales?

En ese punto conviene tener la base bajo tu control. En los planes Pro y Teams, Bolt permite reclamar (claim) una base de Bolt en tu propia cuenta de Supabase. Desde ahí puedes usar la CLI de Supabase y un proyecto de pruebas aparte:

supabase link --project-ref <project-ref>
supabase db pull                         # captura el esquema actual
supabase migration new add_order_status  # crea un archivo de migración vacío
supabase db push                         # aplica las migraciones pendientes
supabase migration list                  # compara local y remoto

Corre cada migración primero en un proyecto de staging y después en producción. Nuestras guías de migraciones con Supabase CLI y de un entorno de pruebas staging explican la configuración, y respaldos de Supabase cuenta qué guarda tu plan por ti.

Respuestas rápidas

¿Puedo deshacer una migración con el historial de versiones de Bolt? No. El historial solo restaura código. Para revertir un cambio de estructura, escribe una migración nueva que lo deshaga y, si hace falta, recupera los datos de tu exportación.

¿Está bien editar desde el editor de tablas? Para los datos, sí. Para la estructura, usa una migración y así el cambio queda registrado y se puede repetir.

¿Por qué desapareció una columna después de un prompt? Lo más probable es que el agente recreara la tabla o renombrara la columna. Busca drop o rename en los archivos de migración o en el chat y recupera los datos desde tu exportación.

¿Necesito migraciones en un prototipo sin usuarios? Menos, pero el hábito cuesta poco y rinde la primera vez que alguien se registra.

¿Tienes que hacer un cambio que no puede salir mal?

Si tu app ya guarda datos de clientes, una segunda mirada antes de tocar la estructura es un seguro barato. Nuestra revisión de seguridad de Supabase cubre esquema, políticas y respaldos, y el servicio para arreglar apps de Bolt resuelve migraciones como arreglos con precio cerrado. Empieza con la revisión gratuita o cuéntanos qué necesitas cambiar. Si un cambio anterior ya rompió algo, mira Bolt rompe la app con cada cambio.