Sqldef : outil de gestion de schéma idempotent pour MySQL, PostgreSQL et SQLite

 (sqldef.github.io)
7 points par GN⁺ 2026-02-10 | 1 commentaires | Partager sur WhatsApp
  • Outil en ligne de commande pour gérer les migrations de base de données en comparant les différences (diff) entre schémas SQL
  • Permet de gérer les schémas RDBMS avec la syntaxe SQL DDL standard
  • Prend en charge les principales bases de données, notamment MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3
  • Le site web propose une démonstration en ligne basée sur une build WebAssembly, permettant d’essayer les fonctions de comparaison de schémas et de génération de DDL
  • Les changements de base de données peuvent être gérés de façon idempotente, ce qui est utile pour une synchronisation de schéma fiable

Aperçu de sqldef

  • sqldef est un outil CLI qui compare deux schémas SQL pour analyser les différences (diff) et générer des instructions DDL sur cette base
    • L’utilisateur peut comparer le schéma existant et le schéma cible afin de déduire automatiquement les modifications nécessaires
    • Les migrations peuvent être effectuées en utilisant directement la syntaxe SQL DDL standard
  • Les bases de données prises en charge sont indiquées comme étant MySQL, MariaDB, TiDB, PostgreSQL, SQL Server, SQLite3

Fonctionnalités de la démo en ligne

  • Le site web propose une Online Demo permettant de visualiser les modifications de schéma
    • L’option « Enable DROP » permet de contrôler l’inclusion ou non des commandes de suppression
    • La section « Up (current → desired) » affiche des exemples de DDL tels que l’ajout de nouvelles colonnes, la création d’index ou l’ajout de contraintes
    • La section « Down (desired → current) » fournit des exemples de modifications inverses, comme la suppression de contraintes

Fonctionnement

  • La démo en ligne utilise une build WebAssembly de sqldef pour effectuer la comparaison (diff) de schémas SQL directement dans le navigateur
    • Elle calcule les différences entre deux schémas et génère automatiquement les instructions DDL nécessaires en résultat
    • Un lien vers le dépôt GitHub permet de consulter le code source de la build WebAssembly

À lire aussi

1 commentaires

 
GN⁺ 2026-02-10
Réactions sur Hacker News

  • Si vous voulez une couverture plus complète pour Postgres, ça peut valoir le coup de regarder pgschema, que j’ai créé
    L’été dernier, je pensais que c’était plutôt abouti, mais en corrigeant une centaine de tickets signalés par les utilisateurs pendant six mois, j’ai compris à quel point j’avais été naïf

    • Très bel outil. On va probablement monter un PoC avec mon équipe
      Je me demande aussi s’il prend en charge la vérification des divergences entre plusieurs clusters de bases de données
    • Ça fait penser à Migra
    • Ça a l’air bien pour les migrations de schéma, mais je me demande comment sont gérés les update/insert quand il faut déplacer de vraies données
    • pg_roll de Xata peut aussi être une alternative à envisager

  • J’ai testé avec SQLite, et pour les migrations délicates comme l’ajout d’une contrainte de clé étrangère sur une table existante, il génère du SQL invalide
    Par exemple, une instruction comme ALTER TABLE books ADD CONSTRAINT fk_books_author FOREIGN KEY (author_id) REFERENCES authors (id) n’est pas autorisée dans SQLite
    Voir la documentation correspondante : SQLite ALTER TABLE

    • Donc au final, pour ajouter une clé étrangère, on se retrouve à devoir supprimer la colonne puis la recréer ?

  • J’utilise Atlas
    Les approches basées sur les migrations et celles basées sur le schéma ont toutes deux des avantages et des inconvénients, donc j’utilise les deux dans un même projet
    L’approche par schéma accélère le développement, et l’approche par migrations permet des déploiements plus fiables

    • Ariel de l’équipe Atlas ici. Une configuration qui combine une approche déclarative en local et une approche versionnée dans les environnements réels est assez courante
      Comme Atlas génère automatiquement les migrations dans les PR, la plupart des développeurs n’ont pas à manipuler eux-mêmes le workflow versionné
      Documentation liée : Declarative vs Versioned Workflows, Atlas Action
    • J’ai moi aussi regardé sqldef et d’autres alternatives avant de tomber sur Atlas
      J’ai apprécié sa prise en charge explicite du migration flow. Je veux savoir exactement quels changements seront appliqués avant un vrai déploiement

  • Je me demande s’il existe un bon outil qui prenne en charge les migrations en arrière-plan
    Par exemple, ajouter une colonne nullable temporaire à une très grosse table, laisser le nouveau code commencer à y écrire des données, remplir ensuite les anciennes données en batch en arrière-plan, puis la passer en non-nullable à la fin
    Ce serait bien d’avoir un outil capable d’exprimer ce type de changement procédural de manière déclarative, et de le relire et tester avec le code
    Pour l’instant, on gère surtout ça avec des scripts temporaires et des consignes de déploiement manuelles

    • J’écris généralement moi-même les migrations de schéma, mais j’utilise surtout grate
      La configuration est simple en environnement de développement, et il existe aussi des exemples comme FastEndpoints-SqlJobQueues

  • Cet outil est vraiment génial
    Grâce à lui, je peux abandonner mon projet perso qui visait à faire la même chose
    À la place, je vais commencer un nouveau projet qui traite un autre problème déjà résolu une centaine de fois — par exemple un petit outil qui surveille les logs systemd et envoie les erreurs par e-mail

  • J’ai apprécié que ce soit un petit outil utile, plutôt qu’un énième gestionnaire de migrations
    Ça donne l’impression de bien compenser les faiblesses de SQL. Je me dis aussi que ce serait bien si c’était déclaratif comme le DDL de Spanner
    Dans Postgres, j’essaie de garder les scripts de schéma idempotents. Je commence avec CREATE TABLE IF NOT EXISTS, puis je garde des ALTER séparés quand j’ajoute de nouvelles colonnes
    Mais avec le temps, les scripts deviennent complexes, et quand tout se stabilise, je fais le ménage dans les instructions ALTER
    Si jamais il faut restaurer une ancienne sauvegarde, un outil comme celui-ci pourrait sans doute rétablir rapidement la compatibilité

  • Je me demande comment ça se compare à Entity Framework ou à sqitch/liquibase
    Je comprends l’approche déclarative, mais sur une grosse base de données de production, les migrations ne sont pas simplement déclaratives
    Un gestionnaire de schéma idéal devrait comprendre le coût des requêtes et les stratégies de réduction du downtime
    Ajouter une colonne ou modifier un index peut déclencher un scan complet de la table

    • Le problème encore plus important, c’est que les données elles-mêmes peuvent faire partie de la migration
      Par exemple, si on scinde Fullname en FirstName et LastName, un simple diff n’exprime que la moitié du problème
      Dans EF Core, les méthodes Up/Down gèrent les transformations réversibles
      Je me demande comment les transformations de données sont traitées sans un concept de ce type

  • De notre côté, nous avons créé en interne un outil de transformation basé sur XML
    XML étant plus facile à parser que SQL, on compare le schéma défini en XML avec la base de données et on applique uniquement les changements nécessaires
    Nous utilisions Sybase SQLAnywhere, et il y avait la complexité supplémentaire de devoir recréer les vues et les index quand des materialized views étaient impliquées dans l’ajout ou la suppression de colonnes
    Nous avons donc ajouté des garde-fous : la suppression de colonnes n’est autorisée que de façon explicite, et les changements de type ne sont effectués que lorsqu’ils sont sûrs
    Cela a rendu les migrations très simples dans des centaines d’installations on-premise
    Il suffit de modifier le XML et l’outil s’occupe du reste, avec la possibilité d’ajouter des fonctionnalités quand c’est nécessaire

  • Avec SQLite, la suppression de colonnes n’est pas bien gérée
    Le support de DROP COLUMN n’a été ajouté que dans les versions récentes, et sur la plupart des appareils, ce n’est toujours pas pris en charge
    Dans l’exemple, j’ai ajouté x integer not null puis essayé un DROP, mais j’obtiens seulement le message « -- Skipped »
    La méthode standard consiste à créer une table temporaire, copier les données puis la remplacer, mais cet outil ne l’automatise pas
    C’est dommage, parce que dès qu’il y a des contraintes, c’est le genre d’opération où l’on se trompe facilement
    Au final, s’il ne gère que les opérations simples, j’ai l’impression qu’il vaut mieux le faire à la main

  • Cet outil semble utile uniquement sur une base de données vide
    Il ne sait pas gérer les migrations de données, et il ne peut donc pas être utilisé sur des tables contenant de vraies données, par exemple si l’on transforme une colonne JSONB en structure normalisée, ou quand il génère ADD COLUMN … NOT NULL lors d’une rétro-migration après suppression de colonne