Migración de entrada y salida
Estado: En desarrollo (ops.migration)
Estado: En desarrollo (ops.export)
Plurabase todavía no tiene migración ni exportación por autoservicio. Durante el piloto, mover un proyecto hacia dentro o hacia fuera se hace con el operador. Como un proyecto de Plurabase ejecuta los mismos servicios open source que Supabase self-hosted, los formatos de datos son estándar: volcados de PostgreSQL 17, objetos de Storage y código Deno de las funciones. Consulta la página de datos para el significado de cada estado.
Trabajos de migración (en desarrollo)
El repositorio tiene código para trabajos de migración que un owner o admin del proyecto de destino inicia con la cadena de conexión del session pooler del origen y un token de acceso de Supabase. Un informe previo enumera cada incompatibilidad antes de escribir nada. Después el trabajo copia la base de datos con sus usuarios de Auth, los objetos de Storage y las Edge Functions, verifica la copia con checksums de filas tomados de una sola instantánea del origen y compara objetos y funciones, y entrega una lista de pasos para el corte. Un reset vuelve a vaciar el destino; después de la verificación no borra nada si el destino cambió desde entonces. Un plan aparte lee los archivos de configuración de un proyecto de Vercel y los nombres de sus variables de entorno, y dice si Sites puede servir su frontend como build estático. Nada de esto está desplegado ni se ha ejecutado contra un proyecto real de Supabase, así que los pasos de abajo siguen siendo la forma de mover un proyecto hoy.
De Supabase a Plurabase
- Inventario (solo lectura). El colector del operador lee los metadatos del proyecto de origen con un token de acceso personal de Supabase escrito en un prompt oculto, nunca en la línea de comandos. Registra la versión de PostgreSQL, las tablas, vistas, políticas RLS, claves foráneas, funciones y triggers de
public, y conteos de Auth, Storage, Functions y Realtime. No exporta filas. Lo que no puede inspeccionar se informa como desconocido, no como no usado. - Plan. La página de migración de la consola (
/platform/migration.html) revisa el inventario y enumera lo que necesita atención, como claves de Vault, otros esquemas o una versión distinta de PostgreSQL. Planificar no cambia nada. - Base de datos. El operador restaura el esquema y los datos en el proyecto nuevo y compara los conteos de filas por tabla. Conserva los esquemas de plataforma que necesita PostgREST (
graphql,graphql_public). Un ensayo con un proyecto del dueño restauró todas las tablas, filas y claves foráneas en una base de datos aislada el 2026-10-15; no se probó iniciar sesión con un usuario migrado. - Auth. Los usuarios y los hashes de sus contraseñas viajan con el esquema
auth. Las sesiones existentes terminan porque el proyecto nuevo tiene su propio secreto JWT, así que los usuarios vuelven a iniciar sesión. - Storage. Los objetos se copian mediante la API de Storage y se comprueban por cantidad y tamaño. Copiar volúmenes de Docker no es una migración.
- Edge Functions. Vuelve a desplegar cada función y escribe de nuevo sus secretos. Antes, copia como archivos locales cualquier import remoto de npm o jsr.
- Frontend. Publica un build estático en Sites, o deja el frontend donde está y cambia su URL de API y su clave publicable.
- Corte. Pausa las escrituras en el origen, mueve los datos finales y después cambia los clientes. No hay corte sin tiempo de inactividad.
De Plurabase a Supabase u otro proveedor
Los mismos pasos funcionan al revés: un volcado de PostgreSQL de tus esquemas y del esquema auth, una copia de los objetos de Storage y el código de tus funciones. Se restauran en Supabase Cloud, Supabase self-hosted o cualquier servidor PostgreSQL 17. El ZIP de tu Site es un build estático común. La exportación por autoservicio existe como código: la pide un owner o admin, y la base de datos del proyecto (todos los esquemas, incluidos auth y storage), los objetos de Storage, el código y los secretos de las funciones y la configuración de Auth llegan en un solo archivo cifrado con age que solo puede descifrar quien la pidió, descargado una sola vez desde un enlace de corta duración, con una herramienta de importación para Supabase self-hosted. Todavía no tiene botón en la consola y no está habilitada en el host del piloto, así que hasta entonces (hito M3) pide el volcado y los objetos al operador.
Qué revisar antes de un corte
- Los secretos de Vault y los secretos de clientes OAuth nunca se mueven solos; configúralos de nuevo.
- Las escrituras nuevas hechas después de un corte no se copian de vuelta si regresas al origen.
- Prueba la aplicación de extremo a extremo contra el proyecto nuevo antes de cambiar a los usuarios.