A hands-on comparison of PostgreSQL monitoring tools - built-in statistics views, pganalyze, pgwatch, PMM, Datadog, cloud-native options, and NeverBlink - with verified pricing and trade-offs for production databases.
PostgreSQL is the most widely used database among developers - 55.6% in the Stack Overflow 2025 survey, a 15-point lead over MySQL. Yet most production incidents we see in client engagements trace back to things nobody was watching: autovacuum falling behind, replication slots retaining WAL until the disk fills, or a connection pool quietly exhausting max_connections.
PostgreSQL monitoring is the practice of continuously collecting the database's cumulative statistics - query performance, connections, replication lag, vacuum health, I/O - and turning them into history, dashboards, and alerts. PostgreSQL exposes all of this through its statistics views, but the views are point-in-time snapshots with no retention and no alerting. Every tool on this list exists to fill that gap, each with a different trade-off between depth, operational burden, and cost.
The list changed meaningfully this year: AWS retired the Performance Insights console on July 31, 2026, and PostgreSQL 18 shipped per-backend I/O statistics that upgrade what you get for free. Here is where things stand.
Quick Comparison
| Tool | Type | Cost | Query-level analysis | History & alerting | Best for |
|---|---|---|---|---|---|
| Built-in statistics views | Native | Free | Yes (pg_stat_statements) | No | The substrate everything else builds on |
| pgwatch | Open-source | Free (self-hosted) | Metrics only | Yes (via Grafana) | Self-hosted, customizable metrics |
| pgBadger | Open-source | Free | Yes (from logs) | Retrospective only | Log-based query forensics |
| PMM (Percona) | Open-source | Free (self-hosted) | Yes (QAN) | Yes | Mixed PostgreSQL/MySQL/MongoDB fleets |
| pganalyze | SaaS | From $149/mo per server | Yes, deepest | Yes | Postgres-only teams wanting advisors |
| pgDash | SaaS | From $100/mo (2 servers) | Yes | Yes | Simple SaaS, core Postgres coverage |
| Datadog DBM | SaaS | $70/db host/mo + infra | Yes, with explain plans | Yes | Existing Datadog shops |
| Cloud-native (AWS/Azure/GCP) | Managed | Free tiers, paid retention | Partial | Yes | Single-cloud managed instances |
| NeverBlink | SaaS (private beta) | Beta signup; paid plans from $29/cluster/mo | Yes, AI root-cause analysis | Yes | Teams that want fixes, not just alerts |
PostgreSQL Monitoring Tools
1. Built-in: the cumulative statistics system
Before adding any external tool, know what PostgreSQL already gives you. pg_stat_activity shows every live backend with its state, wait event, and current query - the first stop for stuck sessions and idle-in-transaction leaks. pg_stat_statements tracks normalized per-query call counts, timing, rows, and buffer usage; it is the substrate nearly every commercial tool on this list builds on. pg_stat_replication exposes replication lag as LSN deltas, and pg_stat_progress_vacuum shows vacuums in flight.
Recent releases keep raising the free baseline. PostgreSQL 16 added pg_stat_io for per-backend-type I/O breakdowns, and PostgreSQL 18 (September 2025) added byte-level I/O columns, per-backend I/O and WAL statistics, and cumulative vacuum timing columns (total_autovacuum_time) on pg_stat_all_tables - so you can finally answer "how much time did autovacuum spend on this table" without third-party tooling. EXPLAIN ANALYZE now includes buffer usage by default, too.
The limitation is structural: these views are counters and snapshots. No history, no graphs, no alerts. Restart the server and most counters reset.
2. pgwatch
pgwatch, maintained by Cybertec, is our pick among self-hosted open-source options. The v3 rewrite in Go (the project has since marched to v5.x, with releases as recent as July 2026) collects metrics defined as plain SQL - which means you can monitor anything you can query - and ships Grafana dashboards plus a web admin UI. Metrics can sink to PostgreSQL, Prometheus, or JSON.
The trade-off is the usual self-hosted one: you run the collector, the metrics store, and Grafana yourself, and alerting is whatever you build in Grafana. There is no query-plan capture and no advisor intelligence. For teams that want Prometheus-native instead, postgres_exporter remains the de-facto standard in Kubernetes environments - actively maintained (v0.20.1, July 2026), though still 0.x with occasional metric renames between minor versions, and dashboards are entirely DIY.
3. pgBadger
pgBadger is a log analyzer, not a live monitor, and that is precisely its value. Point it at PostgreSQL logs with log_min_duration_statement enabled and it produces static HTML reports of the slowest and most frequent queries, temp file usage, lock waits, checkpoints, and vacuum activity. Version 13.2 (December 2025) is current, and the project has been steadily maintained for over a decade.
Two caveats. Report quality depends entirely on your logging configuration - if log_lock_waits and log_checkpoints are off, those sections are empty. And verbose statement logging has real overhead on busy systems, so most teams run it selectively rather than permanently.
4. Percona Monitoring and Management (PMM)
PMM is free, open-source, and covers PostgreSQL alongside MySQL and MongoDB - which makes it the natural choice for mixed database fleets. Its Query Analytics (QAN) gives per-query drilldowns sourced from pg_stat_statements or Percona's enhanced pg_stat_monitor extension. The 3.x line is under active development (v3.9.0 shipped July 2026) with Grafana embedded.
You run the PMM server and clients yourself, and its PostgreSQL-specific advisory depth is thinner than pganalyze's. But at $0 for any scale, with optional paid support from Percona, it is hard to argue with for teams that already operate infrastructure.
5. pganalyze and pgDash
For Postgres-only SaaS monitoring, two products dominate. pganalyze offers the deepest query analysis in this space: an Index Advisor that does what-if index selection, a VACUUM Advisor for bloat and freezing, auto_explain plan collection, and log-based query correlation. Pricing starts at $149/month for one server (Production plan); the Scale plan at $399/month covers four servers and unlocks the VACUUM Advisor.
pgDash is the simpler alternative: the open-source pgmetrics collector feeds a SaaS dashboard covering replication, bloat, locks, and vacuum health. Basic is $100/month for two servers; Pro is $200/month for five with 90-day retention. It lacks pganalyze's advisors and any APM-style tracing, but the coverage of core PostgreSQL health is thorough and the pricing is predictable.
6. Datadog Database Monitoring
If your organization already runs Datadog, its Database Monitoring product adds normalized query metrics, sampled explain plans, and wait/blocking analysis, all correlated with APM traces and logs. That cross-signal correlation is something no Postgres-only tool matches.
The cost is the catch: $70 per database host per month billed annually ($84 on-demand), on top of the underlying infrastructure monitoring ($15-23/host/month). For a fleet of 20 database hosts you are approaching $20k/year before logs and APM. New Relic's PostgreSQL integration is the usage-based alternative - no per-database SKU, billed on data ingest - with a cheaper entry point but less Postgres-specific depth.
7. Cloud-native: Database Insights, Query Store, Query Insights
If you run managed PostgreSQL, start with what the cloud gives you. On AWS, Performance Insights reached end-of-life on July 31, 2026 and its console redirected to CloudWatch Database Insights. Standard mode preserves the familiar DB-load-by-wait-event view with 7-day retention for free; Advanced mode adds fleet dashboards, lock diagnostics, and execution-plan capture, priced per vCPU-hour.
Azure Database for PostgreSQL pairs Query Store with Query Performance Insight and automatic index tuning recommendations. GCP Cloud SQL's Query Insights is free with 7-day retention, and the Enterprise Plus edition extends it with wait-event analysis and an index advisor. The shared limitation: each works only for that cloud's managed service. Self-hosted and multi-cloud fleets need one of the tools above.
8. NeverBlink
NeverBlink approaches the problem from a different angle: instead of another dashboard to watch, it is an AI-native platform that continuously evaluates database health, traces problems to root cause through metrics, logs, and configuration, and prescribes specific fixes - what its makers call the difference between monitoring and maintenance. Built by the team at BigData Boutique on years of production database consulting, it complements existing tools like Grafana or Datadog rather than replacing them, and exposes an API and MCP server so your own automation and AI agents can consume its findings.
PostgreSQL support is currently in private beta (Elasticsearch and OpenSearch are fully supported today, ClickHouse is also in beta), with signup at neverblink.ai. If your team spends more time interpreting graphs than fixing databases, this is the category to watch: not "what is my cache hit ratio" but "your autovacuum settings are why this table bloated, here is the change to make."
Key PostgreSQL Metrics to Monitor
Whatever tool you pick, production PostgreSQL monitoring should cover these:
- Connections: current vs.
max_connections, plus idle-in-transaction sessions, which hold snapshots and block vacuum. - Replication lag and slots: LSN deltas from
pg_stat_replication, and retained WAL per slot inpg_replication_slots- an abandoned slot will eventually fill the disk. - Autovacuum health and wraparound: last vacuum times per table, dead tuple counts, and
age(datfrozenxid)againstautovacuum_freeze_max_age(200M default). Transaction ID wraparound is the failure mode that takes databases fully offline. - Cache hit ratio:
blks_hit / (blks_hit + blks_read)frompg_stat_database; OLTP workloads should sit near 99%. - Locks and blocked sessions:
pg_locksjoined topg_stat_activity; PostgreSQL 18 addslog_lock_failuresfor cheap visibility. - WAL generation and checkpoints: checkpoint frequency from
pg_stat_checkpointer(PostgreSQL 17+); frequent requested checkpoints meanmax_wal_sizeis too small. - Temp files and long-running transactions: temp file spikes point at
work_memsizing; old transactions block cleanup everywhere.
Our Recommendations
Start with the built-ins - enable pg_stat_statements on day one, everywhere. It costs almost nothing and every serious tool depends on it.
For self-hosted open source, pgwatch is the most flexible dedicated option, and PMM wins when PostgreSQL shares a fleet with MySQL or MongoDB. On managed cloud databases, the provider's own insights tooling (Database Insights, Query Store, Query Insights) covers the basics for free - use it before paying for anything.
Teams that want advisory depth without running infrastructure should look at pganalyze; teams already on Datadog should price out Database Monitoring carefully before committing a large fleet to it. And if the goal is spending less time interpreting dashboards altogether, NeverBlink's AI-driven root-cause approach - in private beta for PostgreSQL now - points at where this category is heading.