PWR (PostgreSQL Workload Repository) est un outil de monitoring PostgreSQL pensé pour les DBA, DevOps, SRE et équipes d’exploitation. Il capture des snapshots légers et vous aide à trouver la cause racine des slow queries, locks et autres incidents PostgreSQL en quelques minutes.

Choisissez n'importe quelle paire avant/après - un déploiement, un incident ou une période lente - et PWR calcule instantanément le delta sur les slow queries, lock waits, wait events et les métriques clés.

Oui. PWR est conçu pour un usage sûr en production. Il s'appuie sur un schéma dédié pour ses propres écritures techniques (métadonnées, snapshots), tandis que l'utilisateur applicatif associé à la collecte ne dispose que de droits de lecture sur les catalogues PostgreSQL nécessaires à l'observabilité. Le produit intègre également des mécanismes de purge afin de maîtriser l'espace disque, avec une fréquence de capture et une durée de rétention configurables par l'utilisateur, afin de limiter la charge et le volume de données sur la base.

Oui. PWR est conçu pour l'analyse d'incidents PostgreSQL et la détection de régressions de release - rejouez ce qui s'est passé pendant un incident et identifiez la cause racine sans fouiller dans des logs bruts.

PWR complète votre stack de monitoring PostgreSQL existante en se concentrant sur l'analyse de cause racine : comparaison avant/après, scoring de santé pondéré, et rapports en langage clair lisibles par toute l'équipe.

Oui. PWR utilise un accès en lecture seule, contrôlé par le client, à un schéma dédié créé uniquement pour ses propres objets - il n'écrit jamais dans vos tables applicatives. Vous pouvez révoquer l'accès ou purger/supprimer l'ensemble à tout moment.

Oui, l'essai est gratuit pendant 15 jours. Une carte bancaire est requise à l'inscription.

Oui, vous pouvez annuler à tout moment depuis votre espace, avant la fin des 15 jours.

Vos données restent hébergées chez vous. PWR fonctionne sur votre environnement PostgreSQL, et selon vos exigences de sécurité, vous pouvez choisir l'un des deux modes de déploiement. Vous gardez le contrôle sur l'accès et la rétention des données.

La démo permet de découvrir le produit gratuitement. L'essai vous donne un accès complet pendant 15 jours (carte bancaire requise).

Un monitoring PostgreSQL efficace combine trois niveaux : l'état instantané (sessions actives, connexions, cache hit), l'historique via des snapshots comparables dans le temps, et un score de santé unique qui synthétise ces métriques. PWR capture ces trois niveaux automatiquement, chaque minute, sans configuration complexe.

Identifiez d'abord les requêtes coûteuses avec pg_stat_statements (triées par temps moyen d'exécution), puis confirmez la cause avec EXPLAIN ANALYZE. PWR automatise ce classement et historise chaque requête pour dater précisément l'apparition d'une régression, sans avoir à interroger pg_stat_statements manuellement.

Les sessions bloquées par un verrou apparaissent dans pg_stat_activity avec wait_event_type = 'Lock', et les wait events (CPU, IO, LWLock...) décomposent sur quoi chaque session active attend réellement. PWR affiche ces deux indicateurs en temps réel et les historise pour repérer une contention récurrente.

Activez l'extension via shared_preload_libraries puis CREATE EXTENSION pg_stat_statements, ensuite interrogez la vue en la triant par mean_exec_time, calls ou shared_blks_read selon ce que vous cherchez. PWR va plus loin en capturant son état dans des snapshots persistés, pour comparer deux périodes sans dépendre d'un reset qui effacerait l'historique.

Sélectionnez un snapshot avant et un snapshot après la période à analyser (un déploiement, un incident, un pic de charge) : PWR calcule automatiquement le delta sur les requêtes, les verrous et les métriques clés, et génère un rapport orienté cause racine en quelques secondes.

Oui. PWR se connecte comme un client PostgreSQL standard (lecture seule) : on-premise, VM, conteneur/Kubernetes, ou base managée (RDS, Cloud SQL, Azure Database) - tant qu'une connexion réseau PostgreSQL classique est possible, PWR fonctionne, quelle que soit votre architecture applicative en amont.

Oui. PWR ne pilote pas le failover lui-même, il surveille simplement l'instance PostgreSQL vers laquelle vous le pointez. En cas de bascule (Patroni, repmgr, pg_auto_failover...), pointez PWR vers l'endpoint stable qui suit toujours le primaire actuel (VIP, DNS applicatif ou proxy HAProxy) plutôt que vers une IP fixe, et la surveillance continue sans interruption après un failover.

Oui. PWR s'appuie uniquement sur des vues et catalogues PostgreSQL standards et stables (pg_stat_activity, pg_stat_statements, pg_locks, pg_settings) présents sur toutes les versions majeures actuellement maintenues - aucune dépendance à une fonctionnalité propre à une seule version.

Oui. PWR fonctionne que votre trafic applicatif passe ou non par un pooler comme PgBouncer ou pgpool. Nous recommandons de connecter PWR directement à l'instance PostgreSQL (en contournant le pooler) afin qu'il ait une visibilité complète sur les sessions et ne consomme pas de connexions poolées destinées à l'application.

Non, l'impact est conçu pour être négligeable. PWR n'exécute que des requêtes de lecture légères sur les vues statistiques PostgreSQL, à fréquence configurable (par défaut chaque minute), avec des mécanismes de purge pour maîtriser le volume de données - aucune requête applicative n'est modifiée ou ralentie.

Ça dépend du type de replica. Sur un replica logique (logical replication) : oui, il accepte les écritures, donc le schéma dédié de PWR peut y être installé normalement. Sur un replica physique (streaming replication) : non, il est strictement en lecture seule et PWR a besoin d'écrire dans son schéma dédié pour stocker ses snapshots - installez PWR sur le primaire dans ce cas, ou parlons-en ensemble sur le call pour choisir la bonne topologie selon votre besoin.

Non. PWR ne lit jamais vos données applicatives ni le contenu de vos tables : il s'appuie uniquement sur les catalogues et vues statistiques de PostgreSQL (pg_stat_statements, pg_stat_activity, pg_locks), qui contiennent des métriques agrégées (temps d'exécution, verrous, wait events) - jamais vos données métier ni des informations personnelles (PII).

Oui. Le Tuning Advisor de PWR (Optimiseur Intelligent PostgreSQL) analyse 30 jours de métriques réelles de votre base pour recommander automatiquement les 7 paramètres PostgreSQL les plus déterminants - shared_buffers, work_mem, effective_cache_size, max_connections, maintenance_work_mem, random_page_cost et wal_buffers - chacun avec sa formule, son niveau de sévérité et un score de confiance.