If you are evaluating PostgreSQL monitoring tools, pgwatch is almost certainly on your list. It should be. It is one of the best open-source options available -- mature, lightweight, flexible, and purpose-built for PostgreSQL.
We built myDBA.dev to solve a different problem, and the distinction matters more than you might expect.
What pgwatch Does Well
pgwatch deserves genuine credit. Here is where it excels:
Any SQL query becomes a metric. This is pgwatch's killer feature. Write a SQL query, add it to the configuration, and it shows up in Grafana. Business-specific KPIs, custom health indicators, application-level metrics stored in your database -- if you can SELECT it, pgwatch can track it.
It is free and open source. BSD-3-Clause license, no vendor lock-in, full control. For organizations with strict open-source mandates or zero monitoring budget, this is a decisive advantage.
It scales. The Go-based collector is lightweight enough to monitor hundreds of PostgreSQL instances without becoming a bottleneck. Multiple storage backends -- PostgreSQL, TimescaleDB, Prometheus -- give you flexibility in how you store and query historical data.
Auto-discovery works. Point it at Patroni, PgBouncer, Pgpool2, or AWS RDS and it automatically discovers and monitors all members. Topology changes are handled without manual intervention.
Grafana integration is mature. 30+ predefined dashboards covering database overview, table statistics, index usage, replication, locks, WAL, and more.
The Gap Between Data and Action
Here is the pattern we kept seeing: teams deploy pgwatch, build beautiful Grafana dashboards, and collect comprehensive metrics. Then something goes wrong.
The dashboard shows n_dead_tup at 2.4 million on the orders table. The question is not whether you can see the number -- pgwatch shows it clearly. The question is what you do next.
Is autovacuum disabled on that table? Is a long-running transaction blocking vacuum? Are the per-table vacuum settings misconfigured? What is the exact command to fix it?
-- The fix pgwatch cannot generate for you:
ALTER TABLE orders RESET (autovacuum_enabled);
-- Re-enables autovacuum with default settings
This gap between seeing a metric and knowing what to do about it is where myDBA.dev focuses.
What myDBA.dev Adds
Health Checks with Fix Scripts
pgwatch has no health check system. It collects and displays metrics. Interpretation is left to the operator.
myDBA.dev runs 75+ automated health checks across 12 domains -- Configuration, Performance, Vacuum, Replication, Indexes, Security, Storage, Connections, TimescaleDB, XID Wraparound, pgvector, and Wait Events. Each finding produces three things: what is wrong, why it matters, and a copy-pasteable SQL fix calculated from your actual server configuration.
Index Advisor
pgwatch collects index usage statistics. myDBA.dev goes further: it analyzes your query workload, identifies sequential scans on large tables, detects duplicate and overlapping indexes, and generates CREATE INDEX or DROP INDEX CONCURRENTLY statements with estimated impact.
Automatic EXPLAIN Plans
pgwatch does not collect query execution plans. When a query regresses from 50ms to 12 seconds, you see the timing change in your dashboard but have no plan to explain why.
myDBA.dev automatically collects EXPLAIN plans for your top queries each collection cycle. When performance degrades, you compare old and new plans to see whether the planner switched scan types, whether row estimates drifted, or whether a new join strategy is suboptimal.
Extension Monitoring
pgwatch can store data in TimescaleDB but does not monitor it. It does not track chunk health, compression ratios, continuous aggregate staleness, or job failures. It has no pgvector monitoring for index build progress or recall accuracy. No PostGIS monitoring for spatial index quality or SRID mismatches.
myDBA.dev has dedicated monitoring and health checks for TimescaleDB, pgvector, and PostGIS.
XID Wraparound Protection
pgwatch shows XID age as a metric. myDBA.dev detects wraparound risk, identifies what is blocking autovacuum from making progress (long-running transactions, prepared transactions, replication slots), and generates recovery scripts.
Quick Comparison
| Capability | pgwatch | myDBA.dev |
|---|---|---|
| Open source | Yes (BSD-3-Clause) | No (SaaS) |
| Custom SQL metrics | Yes | No |
| Health checks with fix scripts | No | 75+ checks |
| Index advisor | No | Yes |
| EXPLAIN plan collection | No | Yes |
| Extension monitoring | No | TimescaleDB, pgvector, PostGIS |
| Self-hosting required | Yes | No |
| Price | Free (self-hosted) | Free tier, Pro from GBP 19/mo |
When to Choose pgwatch
Choose pgwatch if your team has deep PostgreSQL expertise and prefers raw data over guided recommendations. If you already run Grafana and Prometheus, pgwatch integrates natively. If you need custom business-domain metrics, pgwatch's SQL-based approach is unmatched. If budget is zero and you have the ops capacity to self-host, pgwatch is the clear winner on cost.
When to Choose myDBA.dev
Choose myDBA.dev if you want the interpretation done for you. If your team does not have a senior DBA who can turn raw metrics into fix scripts, the health check system fills that gap. If you need extension monitoring, EXPLAIN plan collection, or index recommendations, those are capabilities pgwatch does not offer. If you do not want to manage monitoring infrastructure, SaaS means one less thing to operate.
The Bottom Line
pgwatch answers "what is happening?" myDBA.dev answers "what is happening, what does it mean, and what should I do about it?"
Both are good tools solving different problems. The right choice depends on whether your team needs data or direction.
Full comparison with screenshots: MyDBA.dev vs pgwatch
Top comments (0)