Un prompt peut-il remplacer Neon ?

Construis un workflow de « branchement » pour Postgres en utilisant du dump-and-restore plutôt qu’en tentant de reproduire la vraie ingénierie de copy-on-write au niveau du stockage de Neon, ce qui est vraiment hors de portée d’un projet personnel. Utilise un script shell ou une petite CLI Node qui prend le nom d’une base source, lance pg_dump dessus, crée une nouvelle base avec un nom de style « branche », et y restaure le dump — une « branche » qui est une copie complète, réelle et indépendante, pas une copie instantanée à coût zéro. Suis les métadonnées de branche (source, date de création, objectif) dans un petit fichier SQLite local pour pouvoir lister et gérer les branches. Ajoute un utilitaire de « fusion » qui n’est en réalité qu’une étape de rappel et de checklist : comme ce sont des copies de base de données indépendantes, pas des diffs suivis, il n’y a pas de fusion automatique — documente manuellement ce qui a changé et réapplique-le à la base principale, ou exporte un diff de schéma avec un outil comme migra spécifiquement pour les changements structurels. Ajoute une commande de nettoyage qui supprime les anciennes bases de branche au-delà d’un âge configurable. Sois explicite dans le README : ce projet échange la vraie innovation de Neon, des branches instantanées quelle que soit la taille de la base, contre un mécanisme plus simple qui fonctionne bien à petite et moyenne échelle mais devient lent sur de grandes bases, puisque la durée d’un dump-and-restore complet croît avec la taille des données. Ne tente pas de reproduire le branchement en copy-on-write au niveau du stockage — c’est de la vraie ingénierie de systèmes distribués. Nécessite l’hébergement d’une instance Postgres ; aucun autre service externe requis.