Comment comparer deux bases de données Prod et Staging

Quand on parle de comparer deux bases de données Prod et Staging, on parle en fait de deux comparaisons distinctes qu'il est utile de bien séparer. La première concerne le schéma : tables, colonnes, types, contraintes, index. La seconde concerne les données : lignes présentes, valeurs des colonnes, divergences ligne à ligne. Les outils, les workflows et les contraintes ne sont pas les mêmes pour les deux.

Ce besoin revient régulièrement avant un déploiement, après une migration, pour valider qu'un changement s'est bien propagé, ou simplement pour comprendre pourquoi un comportement diffère entre les environnements. Cet article fait le tour des approches courantes et explique comment QoreDB traite le sujet côté client desktop.

Comparer les schémas : pg_dump, Liquibase, Flyway

L'approche la plus directe pour comparer deux schémas PostgreSQL consiste à dumper les deux bases avec pg_dump --schema-only puis à comparer les deux fichiers SQL avec diff. Cette méthode a l'avantage d'être disponible partout, de ne rien installer en plus, et de produire un résultat textuel facile à archiver. Elle a aussi des limites : l'ordre des colonnes ou des contraintes dans le dump peut générer du bruit, et la diff brute reste à interpréter par un humain.

Pour les équipes qui versionnent leurs migrations, Liquibase et Flyway proposent des commandes dédiées. Liquibase fournit diff et diffChangeLog qui produisent directement un changelog applicable. Flyway, dans ses éditions Teams et Enterprise, propose un mécanisme similaire. Ces outils règlent le problème du bruit textuel et s'intègrent à un pipeline CI, mais ils supposent que vous avez déjà adopté l'outil pour gérer vos migrations.

Pour un diff de schéma plus léger sans engagement sur un outil de migration, migra (PostgreSQL) ou schemacrawler (multi-moteurs) génèrent un SQL de migration entre deux bases. C'est utile en ponctuel, notamment avant un déploiement, pour confirmer que la branche de release applique bien ce qui a été préparé en Staging.

Comparer les données : SQL maison ou outils dédiés

Comparer les données est un problème distinct, plus coûteux et plus piégeux. La méthode SQL maison la plus connue repose sur EXCEPT ou MINUS entre deux tables présentes dans le même cluster, ou via une connexion étrangère type postgres_fdw. On obtient les lignes présentes d'un côté et pas de l'autre. C'est simple à écrire, mais ça ne dit pas quelles colonnes diffèrent sur les lignes communes, et ça scanne tout sans filtre.

Une variante plus efficace pour de gros volumes consiste à comparer des checksums par bloc. On découpe la table en plages de clé primaire, on calcule un hash agrégé par plage des deux côtés, et on descend récursivement uniquement dans les plages qui divergent. C'est l'approche qu'utilisent Datafold, data-diff (open source) et plusieurs ETL modernes. Ça marche très bien pour comparer deux warehouses en place, mais l'installation et la configuration ne sont pas anodines.

Quand le besoin est plus interactif, plus exploratoire, plus orienté debug d'un cas précis, ces outils sont surdimensionnés. Un développeur qui veut comprendre pourquoi le produit X est différent en Prod et en Staging veut voir les deux lignes côte à côte, pas configurer un job. C'est là que l'angle GUI prend tout son sens.

L'approche GUI : voir les deux côtés en même temps

QoreDB intègre une fonctionnalité Visual Data Diff dans son interface. L'idée est de réutiliser le même paradigme qu'un diff de code dans Git : deux panneaux côte à côte, surlignage des lignes ajoutées, supprimées, modifiées, et statistiques en bandeau. La source de chaque côté peut être une table directement, ou le résultat d'une requête arbitraire.

Le composant est conçu pour fonctionner entre deux connexions différentes, pas seulement entre deux tables de la même base. On choisit la connexion Prod à gauche, la connexion Staging à droite, le namespace et la table de chaque côté, et l'outil détecte automatiquement les colonnes communes. Les colonnes qui n'existent que d'un côté sont signalées, et les colonnes manifestement temporelles d'audit (created_at, updated_at) sont identifiées comme triviales et peuvent être exclues du calcul.

Le matching des lignes repose sur des colonnes clés. Par défaut, QoreDB tente de détecter la clé primaire des deux tables et l'utilise. Si la détection échoue, ou si on veut comparer sur un autre critère (un identifiant métier, par exemple), l'utilisateur sélectionne explicitement les colonnes de matching dans le panneau de configuration. Sans clé, le diff retombe sur une comparaison ligne à ligne par index, ce qui est rarement ce qu'on veut sur des jeux de données réels.

Pourquoi un diff côté client a du sens

Faire le diff dans le client desktop a quelques propriétés intéressantes. Les deux ensembles de lignes transitent par le poste du développeur, ils ne sont pas exposés à un service tiers, et la comparaison n'écrit rien dans aucune des deux bases. C'est exactement le profil d'un usage interactif, ponctuel, sur des volumes raisonnables : on veut comprendre une divergence sur une table d'une centaine ou de quelques milliers de lignes, pas répliquer en continu.

Pour les très gros volumes, l'approche checksum par blocs reste plus adaptée et c'est ce qu'il faut viser. Le Visual Data Diff de QoreDB n'a pas vocation à remplacer Datafold sur un warehouse de centaines de millions de lignes. Il vise le cas plus fréquent où un développeur ou un SRE veut, en quelques clics, voir où deux environnements divergent et comprendre ce qu'il faut corriger.

Comment ça fonctionne en pratique

Côté usage, on ouvre un onglet Diff dans QoreDB. On configure la source de gauche (connexion Prod, schéma, table ou requête SQL) puis la source de droite (connexion Staging, schéma, table). On lance l'exécution des deux côtés indépendamment, ce qui permet d'ajuster une requête sans refaire l'autre côté. Une fois les deux résultats chargés, on sélectionne les colonnes clés et on déclenche la comparaison.

Le résultat s'affiche dans une grille avec quatre statuts par ligne : inchangée, ajoutée à droite, supprimée à droite, modifiée. Le bandeau de statistiques permet de filtrer rapidement sur un statut, par exemple n'afficher que les modifications. Les cellules dont la valeur diffère sont surlignées dans la grille, ce qui rend le repérage immédiat sur des tables larges. Les résultats peuvent être exportés en CSV ou JSON pour partage ou archivage.

Quelle approche pour quel besoin

En résumé, le bon outil dépend du besoin. Pour un diff de schéma versionnable et applicable, Liquibase ou Flyway font le travail. Pour un dump rapide entre deux serveurs, pg_dump et migra suffisent. Pour une comparaison de données massive et automatisée, l'approche checksum d'outils comme data-diff ou Datafold est la bonne réponse.

Pour le cas interactif que rencontre quotidiennement un développeur, comprendre une divergence ponctuelle entre Prod et Staging sur une table donnée, un client desktop qui montre les deux côtés et surligne ce qui change reste le moyen le plus rapide. C'est ce que QoreDB propose avec son Visual Data Diff, dans la même UI que les onglets de requête et de navigation, sans outil externe à brancher.