TL;DR : PostgreSQL n'est pas livré avec une suite de surveillance intégrée, un gestionnaire de sauvegarde ou un cadre de haute disponibilité — vous assemblez la pile vous-même à partir d'outils spécialisés.
Ce n'est pas une faiblesse : cela signifie que vous choisissez ce qui correspond à votre environnement au lieu de payer pour des fonctionnalités que vous n'utilisez pas.
Cette liste couvre un choix de premier ordre par catégorie, avec de brèves notes sur le moment d'utiliser les alternatives.
Six catégories sont non négociables en production : haute disponibilité/basculement, sauvegarde et restauration à un point dans le temps, mise en commun des connexions, surveillance, analyse des requêtes et analyse des journaux.
Tout le reste est facultatif.
J'ai configuré PostgreSQL dans des environnements de production qui ont succédé à Oracle RAC, à SQL Server AlwaysOn et à du MySQL nu sans aucune haute disponibilité.
La question que l'on me pose le plus souvent est toujours la même : de quels outils ai-je réellement besoin ?
Oracle est livré avec tout intégré — RMAN pour la sauvegarde, Enterprise Manager pour la surveillance, Data Guard pour la réplication, DBMS_SCHEDULER pour les tâches.
PostgreSQL ne le fait pas.
Vous construisez la pile à partir de composants, et chaque composant fait une chose bien.
Voici les outils que j'installe ou que je recommande pour chaque déploiement de production PostgreSQL.
Table des matières
Quels outils sont nécessaires pour exécuter PostgreSQL en production ?
Six catégories sont non négociables : haute disponibilité et basculement, sauvegarde avec récupération à un point précis dans le temps, pooling de connexions, surveillance, analyse des requêtes et analyse des journaux.
Manquer l'un des quatre premiers crée un écart qui coûtera en production.
Tout dans les sections ci-dessous correspond à l'une de ces six options, avec une recommandation principale pour chaque catégorie et des notes claires sur quand les alternatives ont plus de sens.
Haute Disponibilité — Patroni
Patroni est la norme pour la haute disponibilité de PostgreSQL dans les environnements sur site et cloud.
Il gère un cluster de nœuds PostgreSQL, gère l'élection du leader via un magasin de configuration distribué externe (etcd, Consul ou ZooKeeper) et effectue un basculement automatique lorsque le nœud primaire échoue.
Les basculements sont manuels et propres – utiles pour la maintenance planifiée.
L'API REST vous permet d'interroger l'état du cluster, de déclencher des basculements et de vous intégrer à des équilibreurs de charge externes.
Pour la plupart des déploiements sur site, Patroni avec etcd est le bon choix.
La communauté est grande, la documentation est complète et elle gère les cas limites que les outils plus simples manquent.
Quand utiliser les alternatives :
repmgr — plus simple à configurer, moins de surcharge opérationnelle ; idéal pour les environnements plus petits où la pile complète Patroni/etcd est plus que nécessaire.
pg_auto_failover — extension unique, sans dépendances externes ; le moyen le plus simple de basculer automatiquement pour les équipes qui veulent quelque chose qui fonctionne sans gérer etcd.
Stolon — conçu pour Kubernetes ; utilisez-le lorsque le client exécute PostgreSQL sur Kubernetes et souhaite une intégration native.
Si vous migrez depuis Oracle RAC, Patroni est l'équivalent fonctionnel le plus proche pour le basculement automatique.
Ce n'est pas actif-actif — PostgreSQL + Patroni est un modèle maître/réplique avec promotion automatique.
Pour les charges de travail qui nécessitent véritablement le mode actif-actif en lecture/écriture de RAC entre les nœuds, il s'agit d'une réelle différence architecturale qui vaut la peine d'être évaluée séparément.
Sauvegarde et restauration à un instant T — pgBackRest
pgBackRest est le premier outil que j'installe sur chaque serveur PostgreSQL.
Il gère les sauvegardes complètes, différentielles et incrémentielles ; la sauvegarde et la restauration parallèles ; l'archivage des WAL (Write-Ahead Log) ; et la restauration à un point dans le temps.
Il compresse et chiffre facultativement les fichiers de sauvegarde, prend en charge le stockage local et distant, et dispose d'une documentation claire et bien entretenue.
Pour les DBA Oracle, c'est l'équivalent RMAN.
La PITR fonctionne en rejouant les segments WAL à partir d'une sauvegarde de base, ce qui permet une récupération à n'importe quel point dans le temps entre les sauvegardes — le même modèle que la récupération basée sur SCN d'Oracle, exprimé différemment.
Quand utiliser les alternatives :
WAL-G — mieux pour les environnements cloud natifs où les sauvegardes atterrissent dans S3, GCS ou Azure Blob Storage ; plus léger que pgBackRest, pas de fichier de configuration.
Barman — option solide pour les environnements multi-serveurs gérés de manière centralisée ; largement utilisé par les entreprises qui souhaitent un modèle de serveur de sauvegarde dédié.
N'utilisez pas WAL-E pour les nouveaux déploiements — il a été remplacé par WAL-G par le même auteur.
La seule règle qui importe par-dessus tout : testez vos restaurations.
Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde — c'est un fichier.
Planifiez une restauration mensuelle sur un serveur distinct et vérifiez les données.
Pooling de Connexion — PgBouncer
PgBouncer n'est pas facultatif en production.
PostgreSQL crée un nouveau processus système pour chaque connexion client.
Pour de faibles nombres de connexions, cela fonctionne bien.
Aux 500 connexions simultanées, cela devient un problème de performance.
À 2 000, il fait tomber le serveur.
PgBouncer se situe entre l'application et PostgreSQL et multiplexe de nombreuses connexions client sur un petit pool de connexions serveur.
Pour les applications migrant depuis Oracle — où le modèle de serveur partagé d'Oracle ou le pooling de connexions via UCP ou JDBC le géraient de manière transparente — l'ajout de PgBouncer est une étape de migration obligatoire, et non une optimisation optionnelle.
Le choix de configuration qui importe le plus est le mode de pooling :
Mode de transaction — une connexion serveur n'est conservée que pour la durée d'une transaction ; efficacité maximale ; interrompt les applications utilisant des fonctionnalités au niveau de la session (instructions préparées, verrous consultatifs, SET LOCAL).
Mode de session — une connexion serveur par session client ; efficacité réduite ; compatible avec tout ; utilisez cette option si le mode transactionnel provoque des erreurs d'application.
Commencez en mode transaction et passez en mode session uniquement aux sections de trafic qui en ont besoin.
pgpool-II est l'alternative — elle ajoute l'équilibrage de charge des requêtes de lecture sur les répliques en plus de la mise en commun.
Utilisez-le uniquement lorsque vous avez besoin de cette fonctionnalité spécifique ; il ajoute une complexité opérationnelle significative par rapport à PgBouncer.
Surveillance — postgres_exporter et pgwatch2
Aucun outil unique ne couvre toutes les configurations de surveillance, je donne donc deux recommandations en fonction de ce que le client possède déjà.
postgres_exporter — si le client utilise Prometheus et Grafana, c'est la norme.
Il expose les métriques PostgreSQL au format Prometheus, s'intègre aux tableaux de bord existants et dispose de modèles de tableaux de bord Grafana maintenus par la communauté, prêts à être importés.
pgwatch2 — si le client ne dispose pas de Prometheus et souhaite une pile de surveillance autonome, pgwatch2 est livré avec son propre stockage (TimescaleDB ou PostgreSQL) et des tableaux de bord Grafana pré-conçus.
Réduire les frictions de mise en place par rapport à la création de la pile Prometheus à partir de zéro.
Ce qu'il faut surveiller quel que soit l'outil que vous utilisez :
Connexions actives vs max_connections.
Délai de réplication sur les répliques.
Attentes de verrouillage et interblocages.
Activité Autovacuum et gonflement de table.
Requêtes de longue durée.
Taux de succès du cache.
PMM (Percona Monitoring and Management) est l'option full-stack — surveillance, analyse des requêtes et alertes dans un seul package.
Je le recommanderais aux clients qui veulent tout préconfiguré et qui n'ont pas d'infrastructure Prometheus existante.
Lancer PostgreSQL en production pour la première fois après une migration Oracle ?
Je propose une vérification de santé à prix fixe couvrant la configuration HA, la vérification des sauvegardes, le pooling de connexions et la surveillance, livrée sous forme de rapport écrit.
Voir ce que couvre le bilan de santé →
Analyse des requêtes — pgBadger et PEV2
pgBadger est le premier outil que j'exécute lorsque j'enquête sur des plaintes de requêtes lentes après une migration.
Il analyse les fichiers journaux PostgreSQL et génère un rapport HTML présentant les requêtes les plus lentes, les requêtes les plus fréquentes, les attentes de verrouillage, l'activité de connexion et les modèles d'erreur.
Activer déclaration_min_durée_log en postgresql.conf pour capturer les requêtes lentes, puis exécuter pgBadger sur les journaux.
Le rapport donne une image claire de l'endroit où le temps de requête se situe en quelques minutes.
PEV2 (Postgres EXPLAIN Visualizer 2) est un outil en ligne qui prend la sortie de EXPLIQUER (ANALYSER, TAMPONS) et le rend sous la forme d'un diagramme de plan annoté et codé par couleur.
Il rend les plans de requêtes lisibles pour les développeurs et les clients qui ne pensent pas encore en termes de plan d'exécution PostgreSQL.
Utile pour montrer aux clients exactement où une requête perd du temps et pourquoi un changement d'index est utile.
HypoPG est-ce qu'une extension PostgreSQL vaut la peine d'être connue pour les réglages de performance post-migration.
Il vous permet de créer des index hypothétiques — des index qui n'existent que dans la vue du planificateur — et d'exécuter EXPLIQUER contre eux pour tester si un nouvel index aiderait avant de supporter le coût de sa construction sur une grande table.
Ceci est particulièrement utile pendant les 30 à 90 premiers jours après la migration, lorsque les performances des requêtes sont ajustées par rapport aux charges de travail de production réelles.
Extensions que tout DBA de production devrait connaître
Ces six extensions couvrent les lacunes les plus courantes que les administrateurs de bases de données Oracle remarquent après une migration.
| Extension | Remplace ou couvre |
|---|---|
| pg_partman | Automatise la maintenance des partitions — créez, détachez et supprimez des partitions selon un calendrier ; remplace la gestion manuelle du partitionnement par intervalles d'Oracle |
| PGAudit | Enregistrement d'audit détaillé au niveau des sessions et des objets ; l'équivalent le plus proche d'Oracle Unified Auditing ; requis pour les charges de travail de conformité |
| pg_cron | Exécutez des tâches planifiées dans PostgreSQL en utilisant la syntaxe cron ; remplace Oracle DBMS_SCHEDULER pour les tâches récurrentes simples |
| pglogical | Réplication logique entre instances PostgreSQL ; la base des stratégies de migration sans interruption de service |
| pg_stat_monitor | Amélioration du "drop-in" sur pg_stat_statements ; ajout d'histogrammes, de capture de plans de requête et d'informations client |
| plpgsql_check | Analyse statique du code PL/pgSQL ; exécutez-la sur des procédures stockées Oracle converties avant le déploiement pour détecter les erreurs qui ne se manifestent qu'à l'exécution |
Interface graphique et interface en ligne de commande — DBeaver et pgcli
DBeaver est l'outil que je recommande à tout DBA qui passe d'Oracle à PostgreSQL et qui a besoin de travailler simultanément avec les deux bases de données pendant la migration.
Il est gratuit, open-source et prend en charge Oracle, PostgreSQL, MySQL, SQL Server et la plupart des autres bases de données à partir d'une seule interface.
Lors d'une migration, vous comparez souvent des données entre Oracle et PostgreSQL en temps réel — DBeaver gère cela sans changer d'outil.
pgcli est le remplacement en ligne de commande de psql.
Il ajoute la complétion automatique des noms de tables, des noms de colonnes et des mots-clés SQL, la coloration syntaxique et la sortie formatée.
Pour les DBA Oracle habitués à SQL*Plus avec un bon prompt, pgcli supprime la plupart des frictions des premières semaines sur la ligne de commande.
Pour les équipes clientes post-migration : pgAdmin est l'interface graphique gratuite standard et la plupart des équipes la connaissent déjà.
DataGrip (JetBrains) est le choix privilégié pour les équipes fortement composées de développeurs — fonctionnalités IDE complètes, excellent éditeur de requêtes, comparaison de schémas.
Un outil que la plupart des DBA ignorent — postgres-checkup
postgres-checkup exécute une analyse structurée de la santé d'une instance PostgreSQL et produit un rapport détaillé au format Markdown couvrant le "bloat", les index manquants, le risque de "replication slot", les problèmes d'autovacuum, les problèmes de configuration, et plus encore.
Je l'exécute au début de chaque engagement de bilan de santé et à la fin de chaque migration avant la validation.
Cela met en évidence des problèmes qui ne deviendraient visibles qu'en charge de production : des tables avec un "bloat" important, des index qui n'ont pas été utilisés depuis des mois, des slots de réplication qui retiennent les WAL et pourraient remplir le disque.
Il faut moins de dix minutes pour l'exécuter et il produit un rapport que vous pouvez remettre directement à un client.
Foire aux questions
Quel est le meilleur outil de surveillance pour PostgreSQL ?
Pour les équipes utilisant Prometheus et Grafana, postgres_exporter avec un tableau de bord pré-construit est la norme.
Pour les équipes qui souhaitent une pile de surveillance autonome sans avoir à construire une infrastructure Prometheus, pgwatch2 est livré avec un stockage et des tableaux de bord intégrés.
Pour les équipes qui veulent tout pré-emballé, Percona Monitoring and Management (PMM) est l'option complète.
Ai-je besoin de PgBouncer si mon application utilise déjà un pool de connexions ?
Oui, dans la plupart des cas.
Les pools de connexions au niveau de l'application réduisent le nombre de connexions d'un service d'application donné, mais dans les architectures multi-services, chaque service maintient son propre pool.
Le nombre total de connexions côté serveur continue de croître avec le nombre de services et d'instances.
PgBouncer se situe au niveau de la base de données et plafonne le total, indépendamment du nombre de pools d'applications en amont.
Sauvegardes et restauration de PostgreSQL
pgBackRest est l'équivalent le plus proche — il gère les sauvegardes complètes, incrémentielles et différentielles, l'archivage des WAL et la récupération à un instant T.
Pour les environnements cloud, WAL-G est une alternative plus légère qui archive les WAL et les sauvegardes directement sur S3, GCS ou Azure Blob Storage.
Les deux prennent en charge PITR, qui est l'équivalent PostgreSQL de la récupération basée sur les SCN d'Oracle.
Qu'est-ce qui remplace Oracle Enterprise Manager dans PostgreSQL ?
Il n'y a pas d'équivalent unique — la surveillance de PostgreSQL est assemblée à partir de composants.
postgres_exporter alimente Prometheus et les tableaux de bord Grafana en métriques ; pgBadger analyse les journaux de requêtes lentes ; pgwatch2 fournit une pile de surveillance autonome.
Pour une expérience tout-en-un plus complète, Percona Monitoring and Management (PMM) couvre les métriques, l'analyse des requêtes et les alertes sur une unique plateforme.
En résumé
Six catégories, six outils à ne pas négliger : Patroni pour la haute disponibilité (HA), pgBackRest pour la sauvegarde et la restauration à un point dans le temps (PITR), PgBouncer pour la gestion des pools de connexions, postgres_exporter ou pgwatch2 pour la surveillance, pgBadger pour l'analyse des logs, PEV2 pour la visualisation des plans de requêtes.
Les extensions et utilitaires des sections ci-dessus comblent les lacunes que les DBA Oracle remarquent le plus couramment dans les premiers mois après la migration.
La pile n'est pas compliquée — elle est simplement assemblée différemment de ce à quoi les administrateurs de bases de données Oracle sont habitués.
Chaque composant fait une chose bien, et ensemble ils couvrent tout ce que RMAN, Enterprise Manager, RAC et DBMS_SCHEDULER fournissaient dans une seule licence Oracle.
Si vous configurez PostgreSQL en production pour la première fois et que vous souhaitez un second avis sur votre pile, prendre contact →