Migrar

Migrar desde Supabase

Supabase es una plataforma de backend; CapyDB es la base de datos que hay debajo de una. Esta página es honesta sobre cuál de las dos quieres realmente.

01

Lee esto primero

Si usas Supabase para autenticación, almacenamiento, funciones de borde y tiempo real además de la base de datos, pasar a CapyDB significa sustituir cuatro productos, no uno. Puede ser la decisión correcta —normalmente lo es cuando la aplicación se ha quedado estrecha en ese acoplamiento—, pero es un proyecto, no una tarde.

Si usas Supabase sobre todo como Postgres gestionado y lo demás es accesorio, esta es una migración directa y el resto de la página es para ti.

02

Lo que pasa sin cambios

  • -Tu esquema, tus datos, índices, restricciones, funciones y disparadores
  • -Las extensiones, a través del catálogo que se activa por celda
  • -Tus migraciones, sea cual sea la herramienta que las produjo
  • -Todas las bibliotecas cliente, porque la cadena de conexión es una URL postgres:// normal

03

Seguridad por filas

Las políticas de seguridad por filas de Supabase están escritas contra su esquema de autenticación y sus ayudantes de claims de JWT. Eso no existe fuera de Supabase, así que un volcado y restauración directos te dejan políticas que referencian funciones que no están.

La CLI las convierte. El conversor es de código abierto, reescribe las políticas contra ajustes de sesión de PostgreSQL puro e informa de todo lo que no pudo traducir en lugar de emitir algo que permita de más en silencio.

capydb migrate rls ./supabase --out capyrls

04

Autenticación, almacenamiento y funciones

  • -Autenticación: pasa a un proveedor de identidad dedicado y pon los mismos claims en los ajustes de sesión que leen tus políticas convertidas
  • -Almacenamiento: almacenamiento de objetos más URLs firmadas; el codemod mapea la semántica de buckets en los casos habituales y señala el resto
  • -Funciones de borde: lo que ya ejecute tu plataforma de despliegue; son funciones serverless corrientes
  • -Tiempo real: la replicación lógica de PostgreSQL y LISTEN/NOTIFY están disponibles en una celda
  • -La base de datos en sí: esta es la parte que sí es un traslado directo

05

Mover los datos

Importa directamente desde tu cadena de conexión de Supabase. El importador conoce los esquemas de plataforma que no deben viajar y los filtra, así que acabas con tus datos y no con una copia del plano de control de otro.

capydb import \
  --project my-app \
  --source-url "$SUPABASE_DATABASE_URL" \
  --follow

06

El cambio

  • -Importa con seguimiento y ejecuta tu batería de pruebas contra la celda mientras el origen sigue vivo
  • -Aplica las políticas convertidas y pruébalas con una sesión real, no con una conexión de superusuario
  • -Ejecuta capydb doctor para las variables de entorno que aún apuntan al proyecto antiguo
  • -Cambia las cadenas de conexión por entorno, vigila los registros y luego detén el seguimiento
  • -Deja el origen en pie, en solo lectura, una semana: cuesta poco y ha salvado a más de uno

07

Pregúntanos primero

Avísanos antes de un cambio en producción. Revisaremos el plan, estaremos durante la ventana y mantendremos lista una vía de restauración.