Migrar desde Neon

Ambos productos te dan PostgreSQL. La diferencia está debajo: Neon separa almacenamiento y cómputo y ramifica en la capa de almacenamiento; CapyDB ejecuta un proceso PostgreSQL corriente sobre un conjunto de almacenamiento dedicado y lo clona para ramificar. La consecuencia que vas a notar es que una celda de CapyDB se comporta como el Postgres de tu portátil, porque lo es.

Tu esquema, tus consultas, tus extensiones y tus migraciones se mueven sin cambios. Lo que necesita atención es la capa de conexión y todo lo escrito contra un controlador específico del proveedor.

• -Ramificación: las bases de preview son clones con tiempo de vida, una por pull request
• -Escalado a cero: una celda inactiva se duerme y despierta con la siguiente conexión, normalmente en menos de un cuarto de segundo
• -Un endpoint con pooler para entornos serverless y de borde, y otro directo para todo lo demás
• -Restauración a un punto en el tiempo, desde archivado continuo en vez de instantáneas nocturnas
• -Una integración de plataforma para el destino de despliegue en el que ya estás

• -Sin controlador HTTP ni WebSocket: te conectas por el protocolo nativo de PostgreSQL, que todos los controladores ya hablan
• -El aislamiento es un proceso completo y un conjunto de almacenamiento por proyecto, no un inquilino dentro de una capa de cómputo compartida
• -El cómputo es un techo fijo de CPU y memoria por plan, no unidades que autoescalan
• -Las celdas estándar no tienen acceso de red saliente, así que las extensiones que llaman al exterior no están disponibles por construcción

Si tu proyecto importa un controlador serverless específico de Neon, la CLI lo reescribe por ti: el codemod cambia el cliente por un controlador PostgreSQL estándar, corrige la configuración de conexión y señala las llamadas sobre las que no pudo decidir en lugar de adivinar.

# Dry run by default - nothing is written until you say so
capydb migrate codemod neon
capydb migrate codemod neon --write

Inicia una importación contra tu cadena de conexión actual. El modo de seguimiento mantiene la celda nueva sincronizada con el origen mientras pruebas, así que el cambio es una modificación de DNS y de variables de entorno en vez de una ventana de mantenimiento.

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

• -Importa con seguimiento y déjalo corriendo mientras ejecutas tu batería de pruebas contra la celda
• -Ejecuta capydb doctor para detectar variables de entorno que aún apuntan a la base de datos antigua
• -Cambia la cadena de conexión en tu plataforma de despliegue: la integración puede hacerlo por entorno
• -Vigila los registros y el número de conexiones en el panel durante los primeros minutos
• -Detén el seguimiento y desmantela el origen cuando lo veas claro

Para un cambio en producción, avísanos antes de empezar. Revisaremos el plan, estaremos presentes durante la ventana y mantendremos lista una vía de restauración. No te cuesta nada y es la diferencia entre una tarde aburrida y una interesante.