Migrer depuis Neon

Les deux produits vous donnent PostgreSQL. La différence est en dessous : Neon sépare stockage et calcul et crée ses branches au niveau du stockage ; CapyDB fait tourner un processus PostgreSQL ordinaire sur un volume de stockage dédié et clone ce volume pour créer une branche. La conséquence que vous ressentirez, c’est qu’une cellule CapyDB se comporte comme le Postgres de votre portable - parce que c’en est un.

Votre schéma, vos requêtes, vos extensions et vos migrations passent sans changement. Ce qui demande attention, c’est la couche de connexion et tout ce qui est écrit contre un pilote propre au fournisseur.

• -Les branches : les bases de preview sont des clones avec durée de vie, une par pull request
• -La mise à zéro : une cellule inactive s’endort et se réveille à la connexion suivante, généralement en moins d’un quart de seconde
• -Un endpoint via le pooler pour les environnements serverless et edge, et un endpoint direct pour tout le reste
• -La restauration à un instant précis, depuis un archivage continu plutôt que des instantanés nocturnes
• -Une intégration de plateforme pour la cible de déploiement que vous utilisez déjà

• -Pas de pilote HTTP ni WebSocket : vous vous connectez par le protocole natif de PostgreSQL, que tous les pilotes parlent déjà
• -L’isolation, c’est un processus entier et un volume de stockage par projet, pas un locataire dans une couche de calcul partagée
• -Le calcul est un plafond fixe de processeur et de mémoire par formule, pas des unités qui s’ajustent automatiquement
• -Les cellules standard n’ont pas d’accès réseau sortant : les extensions qui appellent l’extérieur sont donc indisponibles par construction

Si votre projet importe un pilote serverless propre à Neon, la CLI le réécrit pour vous : le codemod remplace le client par un pilote PostgreSQL standard, corrige la mise en place de la connexion et signale les appels sur lesquels il n’a pas pu trancher plutôt que de deviner.

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

Lancez un import contre votre chaîne de connexion existante. Le mode de suivi garde la nouvelle cellule synchronisée avec la source pendant vos tests : la bascule devient un changement de DNS et de variables d’environnement plutôt qu’une fenêtre de maintenance.

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

• -Importez en mode suivi et laissez-le tourner pendant que vous passez votre suite de tests sur la cellule
• -Lancez capydb doctor pour attraper les variables d’environnement qui pointent encore vers l’ancienne base
• -Remplacez la chaîne de connexion dans votre plateforme de déploiement - l’intégration peut le faire par environnement
• -Surveillez les journaux et le nombre de connexions dans le tableau de bord pendant les premières minutes
• -Arrêtez le suivi, puis démantelez la source quand vous êtes satisfait

Pour une bascule en production, prévenez-nous avant de commencer. Nous relirons le plan, serons présents pendant la fenêtre et garderons une voie de restauration prête. Cela ne vous coûte rien, et c’est la différence entre une soirée ennuyeuse et une soirée intéressante.