La promesse laissée en suspens

Dans [« Comment j'ai migré 7 applis vers Scaleway »](/blog/migration-gcp-vercel-scaleway), j'avais laissé une phrase en l'air : « la base de données suivra bientôt vers Scaleway Serverless SQL ». Voilà, c'est fait. Et c'est le chapitre le plus délicat de toute la migration : une base de données, ça ne se redéploie pas — ça se déplace, avec tout ce qu'elle contient, sans en perdre une miette.

Règle d'or : zéro octet perdu

Ma base neondb héberge tout — articles, expériences, compétences, médiathèque, activités Strava, pompes… Le principe non négociable : on ne coupe rien tant que tout n'est pas vérifié.

La procédure : pg_dump de Neon → restore dans une base Serverless SQL fraîche → comparaison ligne par ligne, table par table. 14 tables, comptages identiques des deux côtés. Neon reste 100% intact comme filet de sécurité jusqu'à validation complète.

Petit détail piquant : Neon tourne en PostgreSQL 17, Scaleway en 16. Un pg_dump version 16 refuse de lire un serveur 17 → je suis passé par une image Docker postgres:17 pour le dump. Cinq minutes de galère évitées.

L'astuce pour dé-risquer : changer le driver avant l'URL

Mes apps parlaient à Neon via son driver « edge » (@neondatabase/serverless, en HTTP) — qui ne parle qu'à Neon. Scaleway, lui, veut du PostgreSQL standard. Il fallait donc passer à node-postgres.

Le truc malin : node-postgres fonctionne aussi sur Neon. J'ai donc déployé le changement de driver en gardant le pointage vers Neon — les apps tournaient toujours, rien de cassé. La bascule finale n'était alors plus qu'un simple changement d'URL. Le risque, découpé en deux étapes inoffensives au lieu d'un grand saut.

Les deux pièges qui m'ont coûté une heure

1. L'username n'est pas celui qu'on croit. Sur Scaleway Serverless SQL, on s'authentifie avec une clé IAM. Instinctivement, j'ai mis l'access key comme utilisateur. FATAL: password authentication failed, encore et encore, malgré une config identique à une autre base qui marchait. La doc, enfin lue à la loupe : « logins are IAM principal IDs ». L'username, c'est l'ID de l'application IAM, pas l'access key. Une ligne dans la doc, une heure de ma vie.

2. Le search_path vide. Serverless SQL démarre avec un search_path vide. Résultat : SELECT ... FROM blog_posts échoue avec « relation does not exist »… alors que la table est bien là, dans le schéma public. Le fix tient en une ligne, exécutée à chaque connexion : SET search_path TO public.

La bascule, prouvée noir sur blanc

Comme plusieurs apps partagent la même base, on ne bascule pas l'une sans les autres : re-sync final, changement d'URL sur toutes en même temps (via la console, pour ne pas écraser les autres secrets), vérification.

Comment être sûr que les écritures partent bien vers Scaleway et plus vers Neon ? Une sentinelle : j'écris une ligne via l'API, puis je regarde où elle atterrit. Présente dans Scaleway ✅, absente de Neon ✅. La preuve est faite, la sentinelle supprimée.

La boucle est bouclée

Compute, stockage, et maintenant base de données : tout mon écosystème perso est désormais souverain, français, scale-to-zero, sous chetana.fr. Data et calcul enfin co-localisés à Paris — fini les allers-retours transatlantiques vers un serveur américain à chaque requête.

Neon reste quelques jours en filet, le temps d'être serein, puis extinction. Le grand chantier de la souveraineté est terminé. 🇫🇷