Turn on pg_stat_statements and sensible logging first; every tool on this page builds on them. For a free, self-hosted setup, pgwatch (PostgreSQL-specific, Grafana dashboards) or Prometheus with postgres_exporter (if you already run Prometheus) cover metrics, and pgBadger turns logs into slow-query reports. Percona PMM is the free option if you also monitor MySQL or MongoDB. If you want index and VACUUM advice without building anything, pganalyze is the PostgreSQL specialist; if your team already uses Datadog for applications, Datadog Database Monitoring keeps everything in one place. On a managed service, start with the provider's own tool: CloudWatch Database Insights, Cloud SQL Query Insights or Azure Query Store.
PostgreSQL exposes most of what you need to diagnose performance through its cumulative statistics views and its log. What it does not do on its own is keep history, draw charts, alert you, or correlate a slow query with what the server was doing at the time. Monitoring tools fill those gaps, and they differ mainly in where they store the data, how long they keep it, whether they collect execution plans and log events, and how they are priced.
This page is about PostgreSQL specifically. For a cross-engine view see the best database monitoring tools, for free options across engines see the best open source database monitoring tools, and for MySQL see the best MySQL monitoring tools. If you are looking for a client to write queries rather than a monitoring tool, see the best PostgreSQL GUI tools.
Quick picks
pg_stat_statements, pg_stat_activity, auto_explain and log settings are part of PostgreSQL and feed every other tool.
BSD-3-Clause, PostgreSQL-focused, with Grafana dashboards and a choice of metric stores.
Turns PostgreSQL logs into HTML reports of slow and frequent queries, locks, temp files and errors.
Index, VACUUM and query advice built for PostgreSQL, as SaaS or a self-hosted Enterprise Server.
Query metrics, samples and explain plans next to your APM traces and infrastructure metrics.
How we chose
We considered PostgreSQL's built-in statistics and logging, open source tools (pgBadger, pgwatch, Prometheus with postgres_exporter and Grafana, Percona Monitoring and Management), commercial services (pganalyze, Datadog Database Monitoring) and the monitoring features of the three largest managed PostgreSQL services (Amazon RDS and Aurora, Google Cloud SQL, Azure Database for PostgreSQL). To be included, a tool had to be actively released or sold in October 2026, document what it collects from PostgreSQL, and publish its licence or pricing basis.
For each tool we recorded what it collects (query statistics, plans, waits, logs, OS metrics), where the data lives, retention, deployment (agent, SaaS or self-hosted) and the pricing basis. We do not quote overhead figures unless the vendor documents them, and we attribute those that are. The order is not a ranking: built-in features come first, then open source tools, commercial services and cloud consoles.
At a glance
| Tool | Price | Deployment | Collects | Best for | Main trade-off |
|---|---|---|---|---|---|
| Built-in statistics and logging | Free | Part of PostgreSQL | Query stats, sessions, plans in the log | Ad hoc diagnosis | No history, charts or alerts |
| pgBadger | Free (PostgreSQL Licence) | Self-hosted Perl script | Log-based query, lock, temp file and error reports | Slow-query reports from logs | Only as good as your log settings |
| pgwatch | Free (BSD-3-Clause) | Self-hosted collector, Grafana | Metrics via SQL, including pg_stat_statements | Free PostgreSQL dashboards | You run and store everything |
| Prometheus + postgres_exporter | Free (Apache 2.0) | Self-hosted exporter and Prometheus | Server and query metrics as time series | Teams already on Prometheus | Metrics only; no plans or log analysis |
| Percona PMM | Free (AGPLv3 server, Apache 2.0 client) | Self-hosted server plus client | Metrics and Query Analytics | Mixed PostgreSQL, MySQL and MongoDB estates | You host and maintain PMM Server |
| pganalyze | Paid, per server | SaaS or Enterprise Server | Query stats, plans, logs, VACUUM | PostgreSQL tuning advice | PostgreSQL only; cost per server |
| Datadog Database Monitoring | Paid, per database host | SaaS with Datadog Agent | Query metrics, samples, explain plans | Teams standardised on Datadog | Per-host cost on top of other Datadog products |
| CloudWatch Database Insights | Standard mode included; Advanced mode paid | AWS console | DB load, per-query metrics, plans (Advanced) | RDS and Aurora PostgreSQL | AWS only |
| Cloud SQL Query Insights | No additional cost | Google Cloud console | Query load, plans, waits (Enterprise Plus) | Cloud SQL for PostgreSQL | Google Cloud only; edition dependent |
| Azure Query Store (PostgreSQL) | No extra charge | Built into the service | Runtime and wait statistics, optional plans | Azure Database for PostgreSQL | Azure only; not for Burstable tier |
Built-in statistics and logging
pg_stat_statements is a contrib module that records execution statistics for every normalised statement: calls, total and mean execution time, rows, and shared buffer hits and reads. It must be added to shared_preload_libraries (a restart is needed), created with CREATE EXTENSION pg_stat_statements, and needs compute_query_id set to auto or on. This query, from the PostgreSQL documentation, lists the five statements that used the most execution time and their cache hit percentage:
-- PostgreSQL (pg_stat_statements)
SELECT query, calls, total_exec_time, rows,
100.0 * shared_blks_hit /
nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 5;pg_stat_activity shows one row per server process, with its current query, state and wait event, which is where you look for blocked or long-running sessions. auto_explain logs the execution plan of any statement slower than auto_explain.log_min_duration. Server logging settings such as log_min_duration_statement, log_lock_waits, log_temp_files and log_autovacuum_min_duration produce the events that log analysers read. pgAdmin's dashboard also shows live sessions and locks; see the pgAdmin review. For what to do with the results, see the performance tuning and SQL indexes lessons.
- Statistics are cumulative counters with no history; you need something else to sample and store them over time.
- No alerting or charts.
- The PostgreSQL documentation warns that auto_explain.log_analyze adds per-node timing to every statement and "can have an extremely negative impact on performance".
pgBadger
pgBadger is a PostgreSQL log analyser that produces HTML reports with charts of the slowest and most frequent queries, locks, temporary files, connections, checkpoints, autovacuum activity and errors. The latest release when checked was 13.2 (29 December 2025). It reads syslog, stderr, CSV and JSON log formats, can parse remote logs over SSH, and has an incremental mode for daily and weekly reports.
It needs the server to log the right things: the project documents setting log_min_duration_statement and a log_line_prefix that includes a timestamp and process identifier, and recommends log_checkpoints, log_connections, log_lock_waits, log_temp_files and log_autovacuum_min_duration. See pgAdmin vs pgBadger for how it differs from an admin GUI.
- Reports are generated after the fact from logs, not live dashboards or alerts.
- Logging every statement (log_min_duration_statement = 0) produces large logs on busy servers, so most teams set a threshold.
- No execution plans unless you also log them, for example with auto_explain.
pgwatch
pgwatch is a PostgreSQL monitoring tool maintained by CYBERTEC. A Go collector runs SQL-based metric queries against your servers and writes the results to a sink: PostgreSQL, TimescaleDB, Prometheus, JSON files or a custom gRPC backend. Grafana dashboards cover health checks, query performance, index usage, I/O, locks and waits, and it also monitors Patroni, PgBouncer, Pgpool, pgBackRest and WAL-G. You can add your own metrics as SQL.
Version 6.0.0 (15 September 2026) can also scrape existing Prometheus endpoints, rebuilt the dashboards for Grafana 13 and added PostgreSQL 19 support, according to its release notes.
- You host the collector, metric store and Grafana, and handle retention and backups yourself.
- Alerting is configured in Grafana or your metric store rather than in pgwatch itself.
- PostgreSQL only.
Prometheus + postgres_exporter
postgres_exporter is maintained by the prometheus-community organisation under Apache 2.0, with CI testing against PostgreSQL 13 to 18. It exposes server metrics for Prometheus to scrape, and its stat_statements collector (disabled by default) exports pg_stat_statements data. The latest release when checked was 0.20.1 (7 July 2026); 0.20.0 renamed some collectors, so check dashboards and alerts when upgrading.
Prometheus stores the time series and evaluates alert rules, and Grafana (AGPL-3.0) is the usual dashboard layer. This is a good fit when PostgreSQL is one of many systems you already monitor this way. See Prometheus vs Datadog.
- Metrics only: no execution plans, query samples or log analysis.
- You build or import dashboards and alert rules yourself.
- Per-query metrics from pg_stat_statements can create many time series on busy servers, so limit what you export (editorial).
Percona Monitoring and Management (PMM)
PMM is Percona's open source monitoring and management platform. The documentation describes PMM 3.9.1 (19 August 2026). PMM Server is licensed under AGPLv3 and PMM Client under Apache 2.0. It monitors PostgreSQL, MySQL, MongoDB, ProxySQL and Valkey/Redis, on-premises or in the cloud.
Its Query Analytics (QAN) for PostgreSQL uses pg_stat_statements or Percona's pg_stat_monitor extension, and dashboards cover server and host metrics. Percona also lists alerting, Advisors checks, and backup management for some engines.
- You deploy, size and upgrade PMM Server yourself.
- Some PostgreSQL QAN detail depends on installing pg_stat_monitor, which managed services may not offer (editorial: check your provider's extension list).
- Support is through Percona's paid services or the community.
pganalyze
pganalyze is a monitoring service built only for PostgreSQL. Its open source collector (BSD 3-clause) runs in your environment and sends query statistics, plans and log data to the pganalyze cloud or to a self-hosted Enterprise Server. Features include an Index Advisor, Query Advisor, VACUUM Advisor, automated explain plan collection and Log Insights with PII filtering. It documents setup for Amazon RDS and Aurora, Azure Flexible Server, Google Cloud SQL and AlloyDB, Heroku, Crunchy Bridge, Aiven, Supabase, Neon and self-managed servers.
As listed on pganalyze's pricing page on 7 October 2026 (USD, monthly): Production is USD 149 for one server with 14 days of history; Scale is USD 399 for up to four servers plus USD 100 per additional server, with 35 days of history and the Query Advisor, VACUUM Advisor and Log Insights; Enterprise is custom-priced, with 100 days of history and on-premises deployment.
- PostgreSQL only, so mixed estates need a second tool.
- Priced per server, which adds up for many small instances.
- Some advisors and Log Insights are only on the Scale plan and above.
Datadog Database Monitoring
Datadog Database Monitoring (DBM) adds query metrics, query samples, explain plans and database host views to the Datadog platform, and supports Postgres, MySQL, MariaDB, Oracle, SQL Server, MongoDB, Amazon DocumentDB and ClickHouse. For self-hosted PostgreSQL, Datadog documents support for versions 9.6 to 18, Agent 7.36.1 or later connecting directly to the database (not through a pooler), pg_stat_statements in shared_preload_libraries, and track_activity_query_size raised to 4096 so long queries are captured. Datadog states the Agent typically uses less than 1% of query execution time and CPU.
As listed on Datadog's pricing page on 7 October 2026: USD 70 per database host per month billed annually, or USD 84 month to month or on demand. See Prometheus vs Datadog and Datadog vs New Relic.
- A per-host charge on top of any other Datadog products you use.
- SaaS only; monitoring data leaves your network.
- Requires configuration on each database (extension, user, parameters) and a restart for preload changes.
Amazon CloudWatch Database Insights
AWS migrated Performance Insights users to CloudWatch Database Insights, and states that Performance Insights reached end of life on 31 July 2026. Standard mode is the default and includes analysis of DB load by dimension with 7 days of detailed and per-query metrics at no extra cost (longer retention is paid). Advanced mode adds per-query statistics, slow SQL analysis from exported logs, fleet views, and 1 to 24 months of retention included.
For PostgreSQL, Advanced mode also offers SQL lock analysis (Aurora PostgreSQL and RDS for PostgreSQL) and execution plan analysis (Aurora PostgreSQL only). Database Insights can also monitor self-managed PostgreSQL on EC2 through the CloudWatch agent. Pricing is on the CloudWatch pricing page.
- AWS only.
- Execution plan analysis for PostgreSQL is Aurora only, and several features need Advanced mode.
- Feature availability varies by AWS Region.
Google Cloud SQL Query Insights
Query Insights shows database load, top queries, query plans and application tags for Cloud SQL, and Google states there is no additional cost for it on Enterprise or Enterprise Plus instances. The edition matters: Enterprise keeps 7 days of metrics and samples up to 20 query plans a minute; Enterprise Plus keeps 30 days, samples up to 200 plans a minute, and adds wait event analysis, an index advisor, session termination and AI-assisted troubleshooting (preview).
On Enterprise Plus the metrics are stored on the instance disk; Google estimates about 36 GB for 7 days or 155 GB for 30 days. Query Insights is also available for Cloud SQL for MySQL and SQL Server.
- Google Cloud only.
- Wait events and the index advisor need Enterprise Plus.
- Enterprise Plus retention uses instance storage that you pay for.
Azure Database for PostgreSQL Query Store
Query Store is an opt-in feature of Azure Database for PostgreSQL flexible server, available at no extra charge. Setting pg_qs.query_capture_mode to top or all captures runtime statistics in 15-minute windows by default; pgms_wait_sampling.query_capture_mode adds wait sampling, and pg_qs.store_query_plans saves plans. Data is kept for 7 days by default (up to 30) in the azure_sys database, queryable through views such as query_store.qs_view.
Microsoft notes that Query Store is enabled for the whole server, not per database, does not capture queries on read replicas, and should not be enabled on the Burstable pricing tier because it causes performance problems.
- Azure only.
- Retention is limited to 30 days, and at most 500 distinct queries are stored per interval by default.
- Microsoft advises against using it on the Burstable tier.
How to choose
Start by enabling pg_stat_statements and logging slow statements, lock waits, temp files and autovacuum, because every tool here depends on them. Then decide whether you need history and alerts (pgwatch, Prometheus, PMM or a service), log reports (pgBadger) or advice (pganalyze). On RDS, Aurora, Cloud SQL or Azure, try the provider's console first, since it is already enabled or cheap to enable, and add a third-party tool only if you need longer history, cross-cloud views or features it lacks.
Choose a commercial service when the time your team spends running Prometheus, Grafana and storage costs more than the subscription, or when you want PostgreSQL-specific guidance. Choose Datadog or another general platform when application traces and database queries need to be in one place; see database monitoring vs APM. Whatever you pick, trial it on a non-production server first and confirm which features need extensions or restarts on your PostgreSQL version.
Frequently asked questions
Is pg_stat_statements enabled by default?
No. It ships with PostgreSQL as a contrib module, but you must add it to shared_preload_libraries, restart, and run CREATE EXTENSION pg_stat_statements in a database. compute_query_id must be auto or on. Managed services usually let you enable it through parameter settings.
What is the best free PostgreSQL monitoring tool?
It depends on what you already run. pgwatch is the most PostgreSQL-specific free option with dashboards; Prometheus with postgres_exporter fits teams that already use Prometheus; PMM covers PostgreSQL, MySQL and MongoDB together; and pgBadger is the standard free log analyser. All of them need you to host them.
Can pgAdmin monitor PostgreSQL?
pgAdmin's dashboard shows live sessions, locks and activity, which helps with ad hoc checks, but it does not keep long-term history or send alerts. See pgAdmin vs pgBadger.
What happened to Amazon RDS Performance Insights?
AWS states that Performance Insights reached end of life on 31 July 2026 and that its users were migrated to CloudWatch Database Insights, whose Standard mode keeps 7 days of detailed metrics at no extra cost.
How much does PostgreSQL monitoring cost?
Built-in statistics and the open source tools are free apart from the servers and storage you run them on. Commercial services are typically priced per monitored server or host; for example, pganalyze and Datadog Database Monitoring both publish per-server or per-host monthly prices. Cloud provider consoles are free or charge for longer retention and advanced modes.
Sources
- PostgreSQL: pg_stat_statements
- PostgreSQL: The cumulative statistics system
- PostgreSQL: auto_explain
- pgBadger repository and releases
- pgwatch repository and releases
- pgwatch documentation
- postgres_exporter (prometheus-community)
- Grafana repository and licence
- Percona Monitoring and Management documentation
- Percona PMM repository and licences
- pganalyze pricing
- pganalyze documentation
- pganalyze collector (BSD 3-clause)
- Datadog Database Monitoring documentation
- Datadog: Setting up DBM for self-hosted Postgres
- Datadog pricing list
- Amazon CloudWatch Database Insights
- Google Cloud SQL for PostgreSQL: Query insights
- Azure Database for PostgreSQL: Query Store
Checked October 2026.
How we research these guides: our editorial method.