Migration MySQL vers Postgres — quand ça vaut le coup, les pièges et le workflow pgloader

Nous avons migré des bases dans les deux sens : MySQL → Postgres pour les équipes qui ont besoin d'index riches, de vraies sémantiques ACID sur le DDL et de la story JSONB ; Postgres → MySQL pour les équipes qui ont trouvé le modèle de connexion Postgres trop cher pour leur charge. La migration est une vraie pièce d'ingénierie dans les deux sens, et les mauvaises raisons de le faire (« on préfère ») brûleront des mois.

Voici le cadre de décision, les pièges de types de données et le workflow pgloader que nous utilisons quand MySQL → Postgres est le bon choix.

Le point d'entrée pgloader

LOAD DATABASE
  FROM mysql://user:pass@source/dbname
  INTO postgresql://user:pass@dest/dbname
 
WITH include drop, create tables, create indexes, reset sequences,
     workers = 8, concurrency = 1,
     multiple readers per thread, rows per range = 50000
 
CAST type datetime to timestamptz drop default drop not null using zero-dates-to-null,
     type tinyint when (= precision 1) to boolean using tinyint-to-boolean
;

pgloader gère 80 % de la traduction de types automatiquement. Les 20 % restants sont là où l'ingénierie a lieu.

L'article complet couvre :

• Quand la migration est la bonne réponse (et les trois mauvaises raisons courantes)
• Les pièges de types de données : zero dates, tinyint(1) vs boolean, BLOB vs bytea, gestion des jeux de caractères
• Reset des séquences après le chargement de données
• Changements côté application (sensibilité à la casse, performance LIMIT/OFFSET, RETURNING au lieu de SELECT LAST_INSERT_ID)
• Le pattern de cutover dual-write pour les bases en live
• Vérifier les row counts et checksums entre source et destination

Contactez-nous si vous pesez cette migration pour une vraie charge.