Le signal du 24 septembre : bêta 4 et fonctionnalités retirées
La bêta 4 de PostgreSQL 19 est sortie le 24 septembre 2026 sur postgresql.org/about/news/. Le cycle habituel d'une release PostgreSQL prévoit 3 à 4 bêtas avant la disponibilité générale en octobre ; une quatrième bêta en septembre signale que le projet n'a pas atteint le niveau de stabilité cible au moment prévu.
La nouveauté marquante de cette bêta n'est pas un correctif technique — c'est la liste de retrait. L'analyse publiée par l'équipe d'ingénierie de Snowflake dénombre 53 fonctionnalités initialement planifiées pour PostgreSQL 19 qui ont été renvoyées vers une release ultérieure. Ce type de retrait massif en phase bêta est rare dans l'histoire du projet, qui maintient depuis vingt ans une cadence annuelle très régulière.
Conséquence directe : la GA de PostgreSQL 19 est désormais attendue fin octobre 2026, soit un retard de plusieurs semaines par rapport au planning initial. Pour une stack self-hébergée en production, ce décalage n'est pas anodin : il compresse la fenêtre de test avant les gels de fin d'année et décale l'ensemble du calendrier de migration.
Ce qui a été retiré et pourquoi ça compte
Parmi les 53 fonctionnalités retirées, trois groupes méritent l'attention des développeurs qui travaillent avec des stacks applicatives modernes.
Les retraits qui affectent les développeurs applicatifs
- SQL/JSON path improvements — améliorations de la navigation
jsonpathdans les documents JSON imbriqués, très utilisée dans les APIs REST stockant des données semi-structurées (profils utilisateurs, logs applicatifs, configurations dynamiques). Leur retrait signifie que les requêtes qui en dépendaient devront continuer à passer par des alternatives plus verbeuses. - SQL graph queries (ISO SQL:2016) — support des requêtes de graphe au standard ISO SQL:2016, qui aurait permis de modéliser des relations complexes (arbres de catégories, réseaux sociaux, chaînes de dépendances) directement en SQL standard, sans extension. Ce retrait est notable pour les projets qui voulaient migrer de solutions NoSQL vers PostgreSQL.
- MERGE improvements backportés vers PG 18 — les améliorations de la clause
MERGE(ajoutée en PostgreSQL 15, enrichie en 16 et 17) qui devaient figurer dans PG 19 ont été reportées. Une partie a été backportée vers PostgreSQL 18, ce qui renforce rétrospectivement l'attrait de cette version.
Pourquoi ces retraits n'invalident pas PG 19
Un retrait de fonctionnalité en bêta est un signe de maturité, pas d'échec. Le projet PostgreSQL préfère livrer moins que livrer instable — c'est ce qui lui vaut sa réputation de fiabilité en production. Les 53 fonctionnalités retirées seront candidates pour PostgreSQL 20. Ce qui doit retenir votre attention, c'est le calendrier : la fenêtre de test avant la GA est désormais très courte.
Impact concret par stack self-hébergée
La question pratique n'est pas « PostgreSQL 19 est-il bon ? » mais « ma stack tourne-t-elle sur quelle version, et est-ce que PG 19 change quelque chose à mon plan de migration ? ». Les quatre outils les plus répandus sur les VPS self-hosted ont des prérequis documentés qui orientent la réponse.
n8n documente PostgreSQL 14+ comme base supportée. En production self-hosted, les instances n8n tournent majoritairement sur PG 14 ou PG 15 — une migration vers PG 18 est donc un saut maîtrisé, sans fonctionnalités de PG 19 requises par l'application elle-même.
Supabase distribue PostgreSQL 15 par défaut dans son image self-hosted. Le projet suit les releases stables avec un délai de qualification interne de quelques semaines. PG 19 ne sera pas supporté avant plusieurs mois après la GA ; cibler PG 18 pour une instance self-hosted Supabase est la trajectoire cohérente.
Nextcloud 35 indique PostgreSQL 15+ dans sa documentation officielle. Les versions antérieures (Nextcloud 30 à 34) supportaient déjà PG 14. Aucune fonctionnalité PG 19 n'est requise par Nextcloud à ce jour.
Mattermost Team Edition documente PostgreSQL 14+ comme prérequis. La migration vers PG 18 ne nécessite pas de changement applicatif — le schéma est compatible.
Version PostgreSQL requise par application self-hosted
Faites défiler le tableau
| Application | Version PG minimale documentée | Version PG distribuée par défaut | Compatible PG 18 | Nécessite PG 19 |
|---|---|---|---|---|
| n8n | PG 14+ | PG 14 ou 15 selon image | Oui (aucun changement applicatif requis) | Non |
| Supabase self-hosted | PG 15+ | PG 15 (image officielle) | Oui (qualification en cours) | Non |
| Nextcloud 35 | PG 15+ | PG 15 recommandé | Oui | Non |
| Mattermost Team Edition | PG 14+ | PG 14 ou 15 | Oui | Non |
La recommandation : PostgreSQL 18 est la cible intermédiaire saine
PostgreSQL 18 est sorti en disponibilité générale en avril 2026. Il bénéficie d'un cycle de support de cinq ans (jusqu'en 2031) et est désormais stable en production depuis plusieurs mois. C'est la version que les équipes qui planifiaient PG 19 devraient cibler maintenant.
Trois raisons concrètes plaident pour PG 18 comme cible intermédiaire :
1. Les MERGE improvements qui devaient figurer dans PG 19 ont été partiellement backportées vers PG 18 — vous en bénéficiez sans attendre.
2. La migration PG 17 → PG 18 est documentée et sans friction majeure. La compatibilité des extensions courantes (pgvector, PostGIS, TimescaleDB) est assurée.
3. Cinq ans de support à compter d'avril 2026 — pas de pression de mise à niveau immédiate, et une fenêtre confortable pour qualifier PG 19 quand il sera réellement stable en production.
La stratégie correcte est donc : migrer vers PG 18 maintenant, planifier PG 19 pour 2027 (après les premiers retours de production).
Guide de migration PG 16/17 → PG 18
La migration majeure de PostgreSQL s'effectue avec pg_upgrade, l'outil standard du projet. Il nécessite un arrêt de service mais ne demande pas de réinstallation complète — le catalogue et les données sont préservés.
Étapes de migration PG 16 ou PG 17 vers PG 18
Sauvegarder la base avant toute opération
Une migration majeure est irréversible sans sauvegarde. Effectuez un dump complet :
pg_dumpall -U postgres > /backup/pg_full_$(date +%Y%m%d).sqlVérifiez que le fichier est lisible et non vide avant de continuer. Sur un VPS, copiez également le dump vers un stockage externe (bucket S3, serveur distant).
Installer PostgreSQL 18 en parallèle de la version existante
Sur Debian/Ubuntu, le dépôt PGDG permet d'installer plusieurs versions en parallèle :
apt install postgresql-18Les deux instances coexistent (ports différents : 5432 pour l'ancienne, 5433 pour la nouvelle par défaut).
pg_upgradeva opérer la migration entre les deux clusters sans démarrer l'ancienne instance.Arrêter l'ancienne instance et lancer pg_upgrade
Arrêtez proprement l'ancienne instance (PG 16 ou PG 17) :
systemctl stop postgresql@16-main # ou selon votre version systemctl stop postgresql@17-mainLancez
pg_upgradeen mode vérification (--check) d'abord :pg_upgrade \ -b /usr/lib/postgresql/17/bin \ -B /usr/lib/postgresql/18/bin \ -d /var/lib/postgresql/17/main \ -D /var/lib/postgresql/18/main \ --checkSi le check passe sans erreur, relancez sans
--checkpour effectuer la migration.Reconfigurer le port et redémarrer
Après la migration, pointez votre application vers le cluster PG 18. Si vous conservez le port 5432, éditez
/etc/postgresql/18/main/postgresql.conf:port = 5432Démarrez l'instance PG 18 :
systemctl start postgresql@18-mainVérifiez la version active :
psql -U postgres -c "SELECT version();"Analyser et nettoyer après la migration
Après
pg_upgrade, relancez les statistiques sur toutes les bases (requises pour l'optimiseur de requêtes) :vacuumdb --all --analyze-in-stages -U postgresUne fois validé, vous pouvez supprimer l'ancien cluster et ses paquets :
/usr/lib/postgresql/17/bin/pg_dropcluster 17 main apt remove postgresql-17
Vérifier sa version PostgreSQL en production
Avant de planifier quoi que ce soit, connaître la version exacte en production est indispensable. Les commandes varient selon le contexte d'installation.
Commandes de diagnostic de version
- Via psql :
psql -U postgres -c "SELECT version();"— affiche la version complète avec le numéro de patch. - Via systemctl :
systemctl status postgresql— indique le nom du service actif, qui contient le numéro de version majeure. - Via Docker :
docker exec <container> psql -U postgres -c "SELECT version();"pour une instance containerisée. - Via pg_lsclusters (Debian/Ubuntu) :
pg_lsclusters— liste tous les clusters installés, leur port, leur statut et leur version. Utile quand plusieurs versions coexistent. - Via les logs applicatifs : n8n, Supabase et Mattermost logguent la version PostgreSQL au démarrage — vérifiez les logs si vous n'avez pas accès direct au serveur.
Planifier la migration vers PG 19 : timeline et précautions
PostgreSQL 19 GA est attendu fin octobre 2026. La chronologie réaliste pour une adoption en production self-hosted ressemble à ceci :
- Fin octobre 2026 : GA de PG 19, premiers paquets PGDG disponibles.
- Novembre–décembre 2026 : période à éviter pour les migrations en production — gel de fin d'année, équipes en sous-effectif, risque opérationnel élevé.
- Janvier–février 2027 : premier patch de maintenance PG 19 (généralement 2 à 4 semaines après la GA). C'est le signal standard pour considérer un test en staging.
- T1–T2 2027 : qualification sur une instance de staging avec dump anonymisé de production, validation des extensions, tests de performance.
- T2–T3 2027 : migration production pour les équipes qui ont validé le cycle complet.
Trois précautions à ne jamais sauter :
1. Testez d'abord sur un dump anonymisé de production, pas sur des données de test synthétiques — les volumes et les types de requêtes réels révèlent des régressions que les fixtures ne voient pas.
2. Vérifiez la compatibilité de chaque extension avant la migration : pgvector, PostGIS, pg_cron, pg_trgm ont chacun leur propre cycle de qualification pour chaque version majeure.
3. Gardez un plan de rollback documenté : avec pg_upgrade, le retour arrière est possible tant que vous n'avez pas supprimé l'ancien cluster — documentez la procédure de restauration avant de migrer.
Préparer son VPS pour PG 18 avec Docker
Si votre stack tourne déjà sous Docker, la migration vers PG 18 peut se faire en parallèle de l'instance de production, sans pg_upgrade. L'image officielle postgres:18 est disponible sur Docker Hub depuis la GA d'avril 2026.
Déployer PG 18 sur VPS avec Docker Compose
Créer le fichier docker-compose.yml pour PG 18
Créez un répertoire dédié et le fichier de configuration :
mkdir -p /opt/postgres18 && cd /opt/postgres18Contenu du
docker-compose.yml:cat > docker-compose.yml << 'EOF' services: postgres: image: postgres:18 container_name: postgres18 restart: unless-stopped environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} POSTGRES_USER: ${POSTGRES_USER:-postgres} POSTGRES_DB: ${POSTGRES_DB:-app} volumes: - ./data:/var/lib/postgresql/data ports: - "127.0.0.1:5432:5432" EOFCréez un fichier
.envavec vos valeurs :echo 'POSTGRES_PASSWORD=motdepasse_fort_ici' > .envImporter les données depuis l'ancienne instance
Démarrez le nouveau conteneur :
docker compose up -dRestaurez le dump depuis votre ancienne instance (PG 16 ou PG 17) :
psql -U postgres -h 127.0.0.1 -p 5432 < /backup/pg_full_$(date +%Y%m%d).sqlVérifiez que les bases et les tables sont bien présentes :
docker exec postgres18 psql -U postgres -lVérifier et basculer l'application
Avant de basculer l'application, vérifiez la version active dans le conteneur :
docker exec postgres18 psql -U postgres -c "SELECT version();"Mettez à jour la variable
DATABASE_URL(ouDB_HOST/DB_PORT) de votre application pour pointer vers le nouveau conteneur. Redémarrez l'application et vérifiez les logs au démarrage — n8n, Nextcloud et Mattermost logguent tous la connexion PostgreSQL à l'initialisation.
Un VPS avec accès root vous donne la marge que le managé n'a pas
Tester PG 18 en parallèle de votre instance de production, valider votre stack sur un dump anonymisé, et revenir en arrière sans dépendre d'un prestataire : c'est ce que l'accès root sur un VPS rend possible. Un hébergement mutualisé ou un PaaS managé impose le calendrier de mise à niveau du fournisseur — souvent sans préavis sur la version cible ni possibilité de test préalable.
Conclusion : agir maintenant, pas après la GA de PG 19
Le retard de PostgreSQL 19 et le retrait de 53 fonctionnalités ne sont pas des signaux d'alarme sur la qualité du projet — c'est le processus normal de publication d'un logiciel de cette envergure. Mais ils changent le calendrier des équipes qui planifiaient un saut direct vers PG 19 avant la fin 2026.
La fenêtre d'action est maintenant, avant la GA de PG 19 :
- Si vous êtes sur PG 15 ou PG 16 : planifiez la migration vers PG 18. C'est la version stable, supportée 5 ans, dont les fonctionnalités couvrent tous les prérequis des stacks self-hosted courantes (n8n, Supabase, Nextcloud, Mattermost).
- Si vous êtes sur PG 17 : vous êtes dans une bonne position. PG 17 reste supporté jusqu'en 2029 ; la migration vers PG 18 peut attendre un cycle de maintenance calme.
- Dans tous les cas : ne planifiez pas PG 19 en production avant T2 2027 — la qualification des extensions et les premiers retours de prod nécessitent plusieurs mois après la GA.
Le calendrier de migration se décide quand les options sont ouvertes, pas quand la pression opérationnelle ferme les portes.
