Le problème qui a hanté les migrations pendant une décennie
Depuis l'introduction de la réplication logique dans PostgreSQL 10 en 2017, les équipes de développement et d'exploitation disposent d'un outil puissant pour synchroniser des tables entre clusters. Pratique, fiable, largement adopté — mais pas sans angle mort. Et cet angle mort, les développeurs PHP/Symfony qui ont déjà piloté une migration en production le connaissent bien : les séquences n'étaient tout simplement pas répliquées.
Le scénario est classique. Vous répliquez vos tables pendant des heures, vous faites la bascule, vous promouvez le cluster cible, et... ERROR: duplicate key value violates unique constraint. Votre nouvelle base repart à 1 sur ses séquences, alors que vos données migrées contiennent déjà des identifiants bien au-delà de ce seuil. Résultat : des collisions dès le premier INSERT.
PostgreSQL 19 apporte enfin une réponse définitive à ce problème vieux de près de dix ans.
Pourquoi les séquences étaient-elles exclues de la réplication logique ?
Derrière chaque colonne SERIAL, BIGSERIAL ou GENERATED AS IDENTITY se cache une séquence PostgreSQL. Ces objets ont une caractéristique fondamentale qui les rend difficiles à répliquer : ils sont stateful et non transactionnels par conception.
Une séquence avance de façon unidirectionnelle et ne participe pas au mécanisme de rollback standard. Sa valeur courante est stockée dans un fichier système distinct du WAL (Write-Ahead Log) de la base. Or, la réplication logique repose précisément sur le décodage du WAL pour rejouer les opérations sur le cluster cible. Les séquences, évoluant en dehors de ce flux, restaient invisibles au mécanisme de réplication.
Il ne s'agissait pas d'un oubli bénin mais d'une contrainte architecturale réelle. Plusieurs tentatives de patch ont été soumises à la communauté PostgreSQL au fil des années, sans jamais franchir la ligne d'intégration — trop complexes, trop risquées, ou insuffisamment matures.
Ce que Postgres 19 change concrètement
PostgreSQL 19 introduit la synchronisation des séquences dans la réplication logique. Voici ce que cela implique en pratique :
Réplication des séquences à la demande
Il est désormais possible d'inclure des séquences dans une publication logique. La commande CREATE PUBLICATION accepte le mot-clé SEQUENCES pour les englober explicitement :
-- Côté source (publisher)
CREATE PUBLICATION mypub
FOR ALL TABLES, ALL SEQUENCES;
-- Côté cible (subscriber)
CREATE SUBSCRIPTION mysub
CONNECTION 'host=source dbname=myapp user=replicator'
PUBLICATION mypub;
Le subscriber synchronise automatiquement les valeurs courantes des séquences publiées.
Synchronisation lors de la bascule
Pour les migrations avec fenêtre de coupure, une commande dédiée permet de forcer la resynchronisation des séquences juste avant de promouvoir le cluster cible :
-- Sur le subscriber, juste avant la bascule
ALTER SUBSCRIPTION mysub SYNCHRONIZE SEQUENCES;
Cette opération met à jour toutes les séquences abonnées avec leur dernière valeur connue côté source, éliminant le risque de collision au redémarrage.
Comportement non-transactionnel préservé
La communauté a veillé à conserver la sémantique historique des séquences : leur avancement reste non transactionnel. La réplication ne prétend pas offrir une cohérence parfaite au niveau de la milliseconde — elle apporte une synchronisation best-effort suffisante pour les cas d'usage courants (migrations, promotion de standby logique, sharding applicatif).
Impact pour les projets Symfony/PHP
Pour les équipes qui utilisent Doctrine ORM avec PostgreSQL, cette évolution a des répercussions directes.
Migrations zero-downtime : Les architectures qui s'appuient sur la réplication logique pour effectuer des migrations sans interruption de service (blue/green, promote-and-swap) n'ont plus besoin d'étapes manuelles post-bascule pour réarmer les séquences. Le risque d'erreur humaine sous pression disparaît.
Réplication partielle de tables : Si votre application Symfony utilise des publications sélectives (par exemple pour alimenter un reporting secondaire), les séquences des tables concernées peuvent maintenant suivre le mouvement sans script complémentaire.
Moins de colle opérationnelle : Fini les SELECT setval(...) scriptés dans les runbooks de migration. La procédure de coupure se simplifie, et avec elle, la surface d'erreur.
À noter : cette fonctionnalité nécessitera probablement une version de doctrine/dbal compatible avec les nouveaux paramètres de publication, ou une configuration manuelle des publications dans vos scripts de migration Doctrine. Suivez les releases de Doctrine post-sortie de Postgres 19.
Conclusion
L'intégration des séquences dans la réplication logique de PostgreSQL 19 est l'une de ces améliorations discrètes mais à fort impact opérationnel. Elle ne révolutionne pas l'architecture du moteur, mais elle referme une fissure qui forçait les équipes sérieuses à maintenir des procédures manuelles fragiles autour de chaque migration.
Pour les développeurs et DevOps qui s'appuient sur PostgreSQL comme backend de leurs applications Symfony, c'est une excellente nouvelle : un vecteur de panne bien connu vient d'être éliminé à la source.
PostgreSQL 19 n'est pas encore sorti en version stable au moment de la rédaction de cet article, mais les fonctionnalités décrites sont intégrées dans les builds de développement actuels. Restez attentifs aux annonces officielles sur postgresql.org.
📖 Source originale : Looking Forward to Postgres 19: Logically Sequenced — Shaun Thomas, pgEdge (juin 2026)
