Postgres 19 : SPLIT et MERGE PARTITION changent enfin la donne pour vos DBAs

Depuis PostgreSQL 10, le partitionnement déclaratif a transformé la gestion des grandes tables. Chaque version a apporté son lot d'améliorations : joins partition-wise, partitions par défaut, partitionnement par hash, attachement et détachement concurrents. Un vrai succès. Mais il manquait toujours une pièce essentielle : la réorganisation des partitions existantes. Postgres 19, attendu pour la fin 2026, comble enfin ce manque avec deux nouvelles syntaxes : SPLIT PARTITION et MERGE PARTITIONS.

Le problème : réorganiser une partition était une corvée

Imaginez une partition qui grossit trop vite. Vous voulez la découper en plusieurs morceaux plus petits. Jusqu'ici, la procédure ressemblait à ceci :

1. Créer les nouvelles partitions en tant que tables standalone
2. Copier les lignes concernées dans chacune
3. Détacher l'ancienne partition
4. Attacher les nouvelles
5. Supprimer la coquille vide

C'est faisable, mais long, fastidieux et risqué. Chaque étape peut générer des locks qui bloquent les accès en production. Des outils comme pg_partman aident, mais n'éliminent pas la complexité sous-jacente.

L'opération inverse — fusionner plusieurs petites partitions en une seule — était tout aussi laborieuse.

La nouveauté : une seule instruction suffit

Postgres 19 introduit deux nouvelles clauses pour ALTER TABLE :

SPLIT PARTITION

ALTER TABLE events
  SPLIT PARTITION events_2024
  INTO (
    PARTITION events_2024_q1 FOR VALUES FROM ('2024-01-01') TO ('2024-04-01'),
    PARTITION events_2024_q2 FOR VALUES FROM ('2024-04-01') TO ('2024-07-01'),
    PARTITION events_2024_q3 FOR VALUES FROM ('2024-07-01') TO ('2024-10-01'),
    PARTITION events_2024_q4 FOR VALUES FROM ('2024-10-01') TO ('2025-01-01')
  );

En une seule instruction, Postgres redistribue les données de events_2024 vers les quatre nouvelles partitions trimestrielles. Plus besoin de script maison ni de fenêtre de maintenance étendue.

MERGE PARTITIONS

L'opération symétrique permet de regrouper plusieurs partitions en une seule :

ALTER TABLE events
  MERGE PARTITIONS (events_2022_q1, events_2022_q2, events_2022_q3, events_2022_q4)
  INTO PARTITION events_2022;

Très utile pour archiver des données anciennes ou simplifier un schéma qui avait été découpé trop finement.

Ce que ça change concrètement en production

Ces deux instructions ne sont pas juste du sucre syntaxique. Elles apportent des bénéfices opérationnels réels :

Réduction des risques : une opération atomique est moins sujette aux erreurs qu'une séquence de cinq étapes manuelles. En cas d'échec, le rollback est propre.

Moins de locks : Postgres gère en interne la mécanique du déplacement des données, avec une meilleure opportunité d'optimiser les verrous que dans un script utilisateur.

Lisibilité des opérations : les scripts de migration deviennent compréhensibles d'un coup d'œil, ce qui facilite la revue et l'audit.

Intégration naturelle avec pg_partman : les outils existants de gestion du cycle de vie des partitions pourront s'appuyer sur ces instructions pour proposer des workflows encore plus robustes.

Pour les équipes qui gèrent des pipelines analytiques, des tables d'événements volumineuses ou des données time-series, c'est un gain de temps significatif à chaque évolution de stratégie de partitionnement.

Ce qu'il faut garder en tête

Quelques points d'attention avant de foncer :

• Les opérations restent coûteuses : SPLIT et MERGE déplacent physiquement des données. Sur de très grosses partitions, la durée peut être significative. Prévoyez une fenêtre de maintenance ou testez l'impact sur vos workloads.
• Postgres 19 n'est pas encore sorti : au moment de la rédaction de cet article (juin 2026), Postgres 19 est en cours de développement. Les syntaxes présentées ici sont basées sur les patches acceptés, mais peuvent encore évoluer d'ici la release finale.
• Les index et contraintes : vérifiez le comportement des index locaux et globaux lors du split/merge. La documentation finale de Postgres 19 sera votre référence.

Conclusion

Le partitionnement déclaratif de Postgres était déjà puissant. Avec SPLIT PARTITION et MERGE PARTITIONS, il devient enfin complet. Ce qui nécessitait un script de migration délicat et plusieurs étapes risquées se résume désormais à une instruction claire et lisible.

Pour les DBAs et les équipes Ops qui gèrent des bases PostgreSQL en production, c'est l'une des évolutions les plus attendues de ces dernières années. À surveiller de près pour la sortie de Postgres 19.

Source originale : Shaun Thomas — Looking Forward to Postgres 19: Split Personality (pgEdge Blog, juin 2026)