104+ Monitoring & Stats Extensions for PostgreSQL

pg_stat_statements, pg_stat_monitor, pg_qualstats, hypopg, and other Postgres extensions for monitoring and query stats. Ranked by GitHub stars.

Last reviewed: June 5, 2026
25 extensions
AllVector & AIFull-text SearchGeospatialTime-series & TemporalAnalytics & ColumnarForeign Data WrappersMonitoring & Stats
Platform
Self-HostedSupabaseAWS RDSNeonAzureAuroraCloud SQLAlloyDBDigitalOceanCrunchy BridgeAivenHeroku
1
powa
8190 30d

PostgreSQL Workload Analyser-core

Monitoring & Stats·PostgreSQL·Python
2
pg_stat_monitor
579+2 30d

The pg_stat_monitor is a PostgreSQL Query Performance Monitoring tool, based on PostgreSQL contrib module pg_stat_statements. pg_stat_monitor provides aggregated statistics, client information, plan details including plan, and histogram information.

Monitoring & Stats·BSD-3-Clause·C
3
aqo
495+3 30d

Improves the query planner by learning cardinality estimates from prior query executions.

Monitoring & Stats·AGPL-3.0·C
4
pg_tracing
400+3 30d

Distributed Tracing for PostgreSQL

Monitoring & Stats·MIT·C
5
pg_qualstats
3310 30d

An extension collecting statistics about quals

Monitoring & Stats·BSD-3-Clause·C
6
pg_profile
307+4 30d

PostgreSQL load profile repository and report builder

Monitoring & Stats·BSD-2-Clause·C
7
pg_stat_kcache
266+1 30d

Kernel statistics gathering

Monitoring & Stats·BSD-3-Clause·C
8
pg_show_plans
2050 30d

show query plans of all currently running SQL statements

Monitoring & Stats·PostgreSQL·C
9
pgsentinel
188−1 30d

active session history

Monitoring & Stats·PostgreSQL·C
10
pg_wait_sampling
177+3 30d

sampling based statistics of wait events

Monitoring & Stats·PostgreSQL·C
11
system_stats
169+2 30d

EnterpriseDB system statistics for PostgreSQL

Monitoring & Stats·PostgreSQL·C
12
pg_query_state
1600 30d

Inspects a running backend and returns EXPLAIN ANALYZE-style live execution statistics for the query it is currently processing.

Monitoring & Stats·C
13
pg_plan_advsr
118+1 30d

Tunes execution plans automatically through a feedback loop, refining hints via pg_hint_plan and pg_store_plans across repeated runs.

Monitoring & Stats·C
14
bg_mon
750 30d

Background worker that collects per-process and system stats and serves them via an embedded HTTP endpoint.

Monitoring & Stats·MIT·C
15
powa-archivist
730 30d

Core extension for the PoWA Workload Analyzer that gathers PostgreSQL performance statistics for monitoring and tuning.

Monitoring & Stats·PostgreSQL·C
16
pg_store_plans
68+1 30d

track plan statistics of all SQL statements executed

Monitoring & Stats·BSD-3-Clause·C
17
sr_plan
640 30d

Saves and restores query execution plans to lock planner decisions, similar to Oracle's Outline system.

Monitoring & Stats·PostgreSQL·C
18
pgnodemx
550 30d

Capture node OS metrics via SQL queries

Monitoring & Stats·Apache-2.0·C
19
pg_track_settings
54+1 30d

Track settings changes

Monitoring & Stats·PostgreSQL·SQL
20
pg_idx_advisor
510 30d

Analyzes queries with hypothetical indexes and suggests candidate indexes that would improve execution plans.

Monitoring & Stats·PostgreSQL·C
21
bgw_replstatus
350 30d

Small PostgreSQL background worker to report whether a node is a replication master or standby

Monitoring & Stats·PostgreSQL·C
22
pagevis
310 30d

Visualise database pages in ascii code

Monitoring & Stats·MIT·SQL
23
pg_dbms_stats
300 30d

Manages and freezes planner statistics so PostgreSQL can use saved snapshots instead of the latest stats when building execution plans.

Monitoring & Stats·C
24
pg_proctab
290 30d

Exposes the Linux operating-system process table through SQL so load, memory, CPU, and I/O stats can be queried from PostgreSQL.

Monitoring & Stats·PostgreSQL·C
25
pg-telemetry
270 30d

Provides monitoring views and functions covering disk usage, WAL throughput, replication lag, and query sources for Prometheus, Zabbix, or Munin agents.

Monitoring & Stats·PLpgSQL

What is a PostgreSQL Monitoring Extension?

Monitoring extensions expose Postgres internals for performance analysis — query-level execution stats (pg_stat_statements, pg_stat_monitor), filesystem cache reads (pg_stat_kcache), predicate selectivity (pg_qualstats), wait events (pg_wait_sampling), buffer-pool contents (pg_buffercache), and hypothetical indexes for what-if analysis (hypopg). Together they're the foundation of any serious Postgres tuning effort and the data source for tools like PoWA, pganalyze, Datadog's Postgres integration, and AWS RDS Performance Insights.

When to Add a Monitoring Extension

Always enable pg_stat_statements — it's effectively required for any production Postgres deployment, surfaces the queries consuming the most time, and has near-zero overhead. Add pg_stat_monitor when you need time-bucketed query stats with histograms (Percona's enhanced replacement for pg_stat_statements). Add hypopg when you want to test an index without actually creating it — invaluable on large tables where CREATE INDEX takes hours. Skip the more niche stat extensions (pg_qualstats, pg_stat_kcache) until you have a specific performance problem that needs deeper instrumentation — they add overhead and noise to monitoring dashboards.

Frequently Asked Questions

What is pg_stat_statements?
pg_stat_statements is Postgres' built-in extension for tracking query-level execution statistics — it normalizes queries (replaces literals with placeholders), tracks total calls, total time, rows returned, and shared-buffer hits per query template. Query SELECT * FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20; to find your slowest queries by cumulative time. It's the foundation of every Postgres performance dashboard and the first extension to enable on any production deployment.
Should I always enable pg_stat_statements?
Yes — for any production Postgres deployment, the answer is essentially always yes. Overhead is under 1% in measured benchmarks, and the diagnostic value is enormous: you can answer 'what's slow?' in seconds. The one caveat is that it requires shared_preload_libraries and a restart, so add it during initial deployment or a maintenance window. Most managed providers (RDS, Aurora, Supabase, Neon, Azure) have it pre-enabled by default.
What's the difference between pg_stat_statements and pg_stat_monitor?
pg_stat_statements gives cumulative totals — total time, total calls — since the last reset. pg_stat_monitor (Percona's extension) adds time-bucketed aggregation: it splits stats into rolling buckets (e.g. last 5 minutes, last hour) so you can see trends, not just lifetime totals. It also adds histograms of query execution time and tracks more fields per query. For most teams, pg_stat_statements is enough; pg_stat_monitor is worth adopting when you need trending visibility without building it yourself in a metrics system.
How do I find slow queries in Postgres?
Enable pg_stat_statements, then query SELECT query, calls, total_exec_time, mean_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20; for the queries consuming the most cumulative time. Add auto_explain to log query plans for queries over a threshold (e.g. 1 second). For visual analysis, tools like pganalyze, PoWA, and Datadog give you dashboards over the same data. For per-query deep-dives, EXPLAIN (ANALYZE, BUFFERS) shows the actual execution plan.
Does pg_stat_statements work on managed Postgres?
Yes — every major managed provider ships pg_stat_statements enabled by default. AWS RDS, Aurora, Supabase, Neon, and Azure Database for PostgreSQL all support it without configuration. Some providers also expose query stats through their own dashboards (RDS Performance Insights, Aurora Query Insights, Supabase Reports) which read from pg_stat_statements under the hood.

Manage PostgreSQL Visually

1bench is a modern GUI client for PostgreSQL — install extensions, write queries, and inspect schemas without leaving the IDE.

Try 1bench for PostgreSQL