PostgreSQL 19 en beta : construisez votre propre environnement de test avec Docker

Attendre la sortie officielle d'une nouvelle version majeure de PostgreSQL pour commencer à l'évaluer, c'est prendre le risque d'être pris de court lors de la migration en production. La bonne pratique consiste à tester les versions beta dès leur annonce — et Docker rend cela plus accessible que jamais, à condition de savoir contourner une limitation importante des images officielles.

Cet article s'inspire du retour d'expérience d'Andrew Atkinson, ingénieur logiciel spécialisé PostgreSQL, qui a documenté sa démarche pour faire tourner PostgreSQL 19 Beta 1 avec Docker. L'occasion de rappeler un principe fondamental : maîtriser son infrastructure, c'est aussi savoir construire ses propres environnements de test plutôt que de dépendre uniquement des images officielles.

Pourquoi tester les versions beta de PostgreSQL ?

La communauté PostgreSQL publie des versions beta plusieurs mois avant la release finale. Ces phases de test ont un double intérêt :

• Pour la communauté : remonter des bugs, valider les nouvelles fonctionnalités sur des cas d'usage réels, contribuer à la stabilité de la release finale.
• Pour vos projets : anticiper les changements de comportement, identifier les incompatibilités avec vos extensions ou vos requêtes critiques, planifier sereinement la montée de version.

Sur des applications PHP/Symfony qui s'appuient fortement sur PostgreSQL, une montée de version majeure peut impacter les performances de certaines requêtes, le comportement du planificateur de requêtes ou la compatibilité avec des extensions comme pg_stat_statements. Mieux vaut le découvrir en environnement de test que le jour du déploiement.

La limite des images Docker officielles

Premier réflexe naturel : chercher l'image officielle sur Docker Hub. Problème : le dépôt officiel postgres ne publie que les versions stables et finales. Les versions beta, release candidate ou alpha n'y figurent pas.

C'est ici qu'intervient une contribution de la communauté. Un développeur a soumis une pull request sur le dépôt infosiftr/postgres pour ajouter le support de PostgreSQL 19 Beta 1. Cette PR, mergée rapidement, fournit les instructions pour construire l'image localement avec docker buildx.

Cela illustre un point important : les images officielles sont un point de départ, pas une limite. Savoir utiliser docker buildx pour construire une image depuis un Dockerfile distant est une compétence DevOps de base qui ouvre beaucoup de portes.

Construction et lancement de l'environnement

Prérequis

Assurez-vous d'avoir Docker installé sur votre machine. Sur macOS, vous pouvez vérifier votre architecture processeur avec :

uname -m

Cela vous indiquera si vous êtes sur ARM (Apple Silicon) ou x86/AMD64, ce qui peut influencer le choix de l'image de base.

Construction de l'image PostgreSQL 19 Beta 1

La commande suivante télécharge et construit l'image postgres:19beta1-trixie directement depuis le dépôt GitHub communautaire :

docker buildx build -t postgres:19beta1-trixie \
  'https://github.com/infosiftr/postgres.git#19-rc:19/trixie'

Quelques points à noter :

• trixie fait référence à la base Debian utilisée pour l'image.
• Le tag 19-rc pointe vers la branche de la release candidate dans le dépôt source.
• La construction peut prendre quelques minutes selon votre connexion et votre machine.

Lancement du conteneur

Une fois l'image construite, lancez le conteneur avec :

docker run \
  --name pg19 \
  --env POSTGRES_USER=postgres \
  --env POSTGRES_PASSWORD=postgres \
  --detach postgres:19beta1-trixie

Vérifiez que le conteneur est bien en cours d'exécution :

docker ps -a

Et consultez les logs si nécessaire :

docker logs -f pg19

Connexion via psql

Pour vous connecter au serveur PostgreSQL 19 depuis votre machine hôte :

docker exec -it pg19 psql -U postgres

Une fois connecté, confirmez la version :

SELECT version();

Vous devriez voir apparaître PostgreSQL 19beta1.

Ce que PostgreSQL 19 apporte à tester en priorité

Une fois l'environnement opérationnel, la question est : que tester en priorité ?

Andrew Atkinson mentionne notamment les évolutions apportées à pg_stat_statements, une extension incontournable pour le monitoring des performances de requêtes. PostgreSQL 19 enrichit les métriques disponibles dans cette vue, ce qui peut directement impacter vos outils d'observabilité si vous les avez construits autour de cette extension.

D'une manière générale, pour un projet Symfony/PHP, voici les axes de validation recommandés lors d'un test de version beta :

• Compatibilité des extensions : vérifiez que vos extensions compilent et fonctionnent correctement avec la nouvelle version.
• Plan d'exécution des requêtes critiques : utilisez EXPLAIN ANALYZE sur vos requêtes les plus sollicitées pour détecter d'éventuelles régressions.
• Comportement de pg_stat_statements : si vous monitorez vos requêtes via cette extension, validez que vos dashboards et alertes fonctionnent toujours comme attendu.
• Nouvelles fonctionnalités SQL : évaluez si certaines nouveautés peuvent simplifier ou optimiser votre code applicatif.

Conclusion : l'autonomie comme bonne pratique d'infrastructure

Dépendre exclusivement des images Docker officielles pour tester de nouvelles versions de vos outils, c'est accepter de ne jamais pouvoir agir en avance de phase. La démarche décrite ici — construire soi-même une image à partir d'une source communautaire fiable — est simple à mettre en œuvre et représente un investissement minimal pour un gain de contrôle significatif.

Sur des projets où PostgreSQL joue un rôle central, anticiper les montées de version en testant les betas est une pratique de maturité technique. Elle permet de documenter les impacts, de préparer les scripts de migration et d'aborder la release finale avec sérénité.

📖 Source originale : Beta Testing PostgreSQL With Docker par Andrew Atkinson.