Lovable Supabase migrations: cómo funcionan sin romper tu app

En Lovable, las migraciones de Supabase (Lovable Supabase migrations) son los archivos SQL que cambian la estructura de tu base de datos: crear tablas, agregar columnas, poner reglas de seguridad. Lovable las escribe por ti, te las muestra en el chat para que las apruebes, las ejecuta en tu proyecto de Supabase y las guarda en la carpeta supabase/migrations/ de tu código. Si entiendes ese flujo, evitas la mayoría de los errores de “la app dice que no existe la columna”.

Cómo funciona la integración de Lovable con Supabase

Según la documentación de la integración a noviembre de 2026:

1. Pides algo en el chat (“agrega un campo de teléfono a clientes”).
2. Lovable escribe el SQL del cambio y te lo muestra para aprobarlo antes de ejecutarlo.
3. Al aprobar, lo corre en tu Supabase, guarda el archivo en supabase/migrations/ y regenera los tipos de TypeScript (la descripción de tus tablas que usa el código).
4. Insertar o modificar datos también requiere tu aprobación. Las consultas de solo lectura para depurar no cambian nada.

Un archivo de migración típico se ve así:

-- supabase/migrations/20261106120000_add_phone_to_clientes.sql
alter table public.clientes add column telefono text;

El nombre empieza con fecha y hora, y así Supabase sabe en qué orden aplicarlos.

Qué revisar antes de aprobar una migración

No necesitas saber SQL a fondo, pero sí leer con cuidado:

• drop table o drop column: borra datos. Si no pediste eliminar algo, no lo apruebes.
• disable row level security: apaga la seguridad de la tabla. Casi nunca es lo que quieres. Lee qué es Supabase RLS.
• Políticas con using (true): permiten que cualquiera lea o modifique. Revisa ejemplos de políticas RLS.
• Cambios de tipo de columna en tablas con datos: pueden fallar o truncar información.

Lovable Supabase connection: cómo conectar tu proyecto

Hoy Lovable trae su propio backend integrado (Lovable Cloud) activado por defecto. Si quieres usar tu propio Supabase:

1. Un dueño o admin del workspace liga la organización de Supabase desde Connectors en la barra lateral, o desde Settings → General → External Supabase dentro de un proyecto.
2. En el proyecto, abre Settings → General → External Supabase, da clic en Connect y elige el proyecto en Connect project.
3. Verifica en More → Supabase: debe aparecer el nombre del proyecto, su estado y enlaces al panel.

Si otro proyecto de Lovable ya usa ese mismo Supabase, verás una advertencia: los proyectos que comparten Supabase se sobreescriben los secretos, incluido LOVABLE_API_KEY. Usa un Supabase por proyecto.

Si tu proyecto ya está en Lovable Cloud y quieres pasarlo a tu Supabase, no hay conversión automática; sigue nuestra guía para migrar Lovable Cloud a Supabase.

Para desconectar: More → Supabase → Disconnect. Lovable deja de desplegar funciones y de leer el esquema, pero no borra nada de Supabase ni cambia tu código.

Aplicar las migraciones en otro proyecto de Supabase

Un caso frecuente: quieres un Supabase de pruebas y otro de producción, o recrear la base en un proyecto nuevo. Como las migraciones están en tu repositorio, un desarrollador puede aplicarlas con la CLI de Supabase:

npx supabase login
npx supabase link --project-ref TU_PROJECT_REF
npx supabase db push

db push aplica, en orden, las migraciones que el proyecto destino todavía no tiene. Esto crea la estructura, no copia los datos.

Errores comunes con las migraciones

“column does not exist” o “relation does not exist”

El código espera una columna o tabla que no está en la base. Causas típicas: una migración falló a medias, rechazaste una migración pero el código sí se cambió, o estás apuntando a otro proyecto de Supabase. Pídele a Lovable que revise si todas las migraciones de supabase/migrations/ están aplicadas.

Cambios hechos a mano en el panel de Supabase

Si creaste una tabla desde el Table Editor de Supabase, ese cambio no existe como archivo de migración. Funciona hoy, pero cuando recrees la base en otro lado, faltará. Lo sano es que cada cambio de estructura pase por una migración.

Una migración que choca con datos existentes

Por ejemplo, hacer obligatoria (not null) una columna que ya tiene filas vacías. La migración falla. Primero hay que llenar los valores y después aplicar la restricción.

Error 400 al guardar después de una migración

Suele ser una política RLS o un tipo de dato que no coincide. Tenemos una guía del error 400 de Supabase.

Respaldo antes de una migración delicada

Si la migración borra, renombra o cambia el tipo de una columna en una tabla con datos reales, saca un respaldo antes de aprobarla. Revisa primero qué respaldos automáticos tiene tu proyecto en Database → Backups del panel de Supabase (depende del plan). Además, con la CLI puedes guardar una copia propia:

npx supabase db dump -f estructura.sql
npx supabase db dump --data-only -f datos.sql

Guarda esos archivos fuera del repositorio si contienen datos de clientes: no deben subirse a GitHub.

Cómo deshacer una migración

Supabase no tiene un botón de “deshacer” para una migración ya aplicada. Lo correcto es una migración nueva que revierta el cambio. Por ejemplo, si agregaste una columna por error:

-- supabase/migrations/20261106130000_remove_telefono_from_clientes.sql
alter table public.clientes drop column telefono;

Nunca borres ni edites a mano un archivo de migración que ya se aplicó: la historia del repositorio y la de la base dejan de coincidir y las siguientes migraciones pueden fallar. Si la migración borró datos, no hay SQL que los recupere; ahí solo sirve el respaldo.

Pídele a Lovable exactamente eso: “crea una migración nueva que revierta la anterior, sin modificar los archivos existentes, y muéstramela antes de aplicarla”.

Cuándo pedir ayuda

Aprobar migraciones sin leerlas es la forma más común de borrar datos o dejar tablas abiertas en apps hechas con IA. Si tu base ya tiene información real y las migraciones empezaron a fallar, o no sabes si lo que aprobaste dejó algo expuesto, conviene una revisión antes de seguir construyendo encima. En Black Engine lo revisamos por WhatsApp.