Flyway et Liquibase répondent au même problème (versionner et appliquer les changements de schéma d’une base de données de façon reproductible), mais avec des philosophies suffisamment différentes pour que le choix entre les deux dépende moins de fonctionnalités comparées une à une que d’un pari sur la façon dont l’équipe préfère penser ses migrations, une question déjà effleurée dans l’article sur les migrations de base de données en pipeline CI/CD sans jamais trancher entre outils.

Flyway : du SQL versionné, immuable, rien de plus

Flyway fait reposer chaque migration sur un fichier SQL brut, nommé selon une convention de version stricte (V1__create_table.sql), appliqué une seule fois et jamais modifié après coup : une fois exécutée, une migration Flyway est immuable, toute correction nécessitant une nouvelle migration plutôt qu’une modification de l’existante.

-- V2__add_email_column.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);

Cette simplicité volontaire signifie qu’un développeur SQL peut lire et écrire une migration Flyway sans apprendre d’abstraction supplémentaire, au prix d’un SQL généralement spécifique au SGBD cible, peu portable d’un moteur de base de données à un autre sans réécriture.

Liquibase : un changelog déclaratif, agnostique du SGBD

Liquibase décrit chaque changement dans un format structuré (XML, YAML, JSON, ou SQL) appelé changelog, une couche d’abstraction que Liquibase traduit ensuite en SQL spécifique au SGBD cible au moment de l’exécution.

# changelog.yaml
- changeSet:
    id: add-email-column
    author: team
    changes:
      - addColumn:
          tableName: users
          columns:
            - column:
                name: email
                type: varchar(255)

Cette abstraction permet en théorie de faire tourner le même changelog contre PostgreSQL ou MySQL sans réécriture, un avantage réel pour qui gère plusieurs moteurs de base de données, mais qui ajoute une couche de traduction à comprendre et déboguer quand le SQL généré ne correspond pas exactement à ce qu’on attendait.

Le rollback : une promesse à nuancer des deux côtés

Liquibase propose un mécanisme de rollback déclaratif (rollback associé à chaque changeSet), une fonctionnalité native que Flyway (dans son édition gratuite) ne propose pas directement, orientant plutôt vers l’écriture d’une migration de correction en avant. Cette différence est réelle, mais rejoint la nuance déjà posée dans l’article sur les migrations en pipeline : un rollback de schéma reste risqué dès que des données ont été écrites entre-temps dans les colonnes concernées, peu importe l’outil utilisé pour l’exécuter.

Le vrai critère de choix

Le choix entre les deux ne se résout pas à « lequel a le plus de fonctionnalités », mais à une question plus simple : l’équipe préfère-t-elle écrire du SQL brut directement compris par tous les développeurs SQL de l’équipe (Flyway), ou une abstraction déclarative qui facilite la portabilité multi-SGBD et le rollback structuré au prix d’une couche supplémentaire à maîtriser (Liquibase) ? Une équipe mono-SGBD avec des développeurs à l’aise en SQL penche naturellement vers Flyway ; une équipe gérant plusieurs moteurs de base de données ou cherchant un rollback structuré par défaut trouve dans Liquibase un compromis déjà pensé pour ce besoin.

À retenir

Flyway impose des migrations SQL versionnées et immuables, une simplicité qui ne demande aucune abstraction supplémentaire mais reste généralement liée au SGBD cible. Liquibase ajoute une couche de changelog déclaratif traduite en SQL au moment de l’exécution, portable entre plusieurs SGBD et dotée d’un rollback structuré, au prix d’une abstraction de plus à comprendre. Le critère de choix n’est ni la popularité ni une liste de fonctionnalités, mais la préférence de l’équipe entre SQL brut directement lisible et changelog déclaratif portable, une décision d’outillage à prendre en amont plutôt qu’à corriger après coup une fois les migrations déjà écrites dans un format donné.