MyDBA.dev vs pgwatch: Metrics Collection vs Actionable Intelligence

MyDBA.dev vs pgwatch: Metrics Collection vs Actionable Intelligence

pgwatch is one of the best open-source PostgreSQL monitoring tools available. It is mature, flexible, and purpose-built for PostgreSQL. If you are evaluating monitoring options, pgwatch absolutely belongs on your shortlist.

But there is a fundamental difference in philosophy between pgwatch and myDBA.dev that goes beyond feature checklists. pgwatch collects metrics beautifully. myDBA.dev collects metrics AND tells you what to do about them. That distinction matters more than you might think at 2 AM when something breaks.

The Quick Summary

| Capability | pgwatch | myDBA.dev | |---|---|---| | Open source | Yes (BSD-3-Clause) | No (SaaS) | | Metrics collection | Excellent | Excellent | | Custom SQL metrics | Yes (any SQL = a metric) | No | | Storage backends | PostgreSQL, TimescaleDB, Prometheus | Managed (TimescaleDB) | | Grafana dashboards | Yes (30+ predefined) | Built-in dashboards | | Auto-discovery | Patroni, PgBouncer, Pgpool2, RDS | Connection-based | | Health checks with fix scripts | No | Yes (75+ checks) | | Index advisor | No | Yes | | EXPLAIN plan collection | No | Yes (automatic) | | XID wraparound remediation | Metrics only | Detection + recovery scripts | | Extension monitoring | No | TimescaleDB, pgvector, PostGIS | | Alerting | Via Grafana | Built-in with digest emails | | Self-hosting required | Yes | No | | Pricing | Free | Free tier, Pro from GBP 19/mo |

Where pgwatch Excels

pgwatch deserves genuine respect. It has been around since 2016, maintained by Cybertec, and has earned its place in the PostgreSQL ecosystem. Here is where it genuinely shines:

It is free and open source. BSD-3-Clause license means you can run it anywhere, modify it however you want, and never pay a licensing fee. For organizations with strict open-source requirements or zero monitoring budget, this matters enormously.

Any SQL query becomes a metric. This is pgwatch's killer feature. If you can write a SQL query, you can turn it into a monitored metric. Want to track a business-specific KPI stored in your database? Write the query, add it to pgwatch, and it shows up in Grafana. No other tool makes custom metrics this effortless.

It scales to hundreds of instances. pgwatch is lightweight enough to monitor large fleets without becoming a bottleneck. The collector is written in Go, resource usage is minimal, and you can distribute collection across multiple gatherers.

Storage flexibility. pgwatch supports PostgreSQL, TimescaleDB, and Prometheus as storage backends. If your organization already has a Prometheus and Grafana stack, pgwatch slots right in. If you prefer TimescaleDB for long-term retention, that works too.

Auto-discovery. Point pgwatch at your Patroni cluster, PgBouncer pool, or AWS RDS account, and it automatically discovers and monitors all members. When your cluster topology changes, pgwatch adapts without manual reconfiguration.

Mature Grafana integration. pgwatch ships with 30+ predefined Grafana dashboards covering database overview, table statistics, index usage, replication, locks, WAL, and more. If your team already lives in Grafana, pgwatch is a natural fit.

For teams with strong PostgreSQL expertise who primarily need data collection and visualization, pgwatch is an excellent choice. It gives you the raw materials to build your own monitoring practice.

Where myDBA.dev Goes Further

The difference is what happens after the data is collected.

From Metrics to Action

pgwatch shows you that n_dead_tup is 2.4 million on your orders table. You see the number in Grafana, maybe you set an alert threshold. But what do you do about it? You need to know whether autovacuum is disabled, whether the table has custom vacuum settings, whether a long-running transaction is blocking vacuum, and what the exact fix command is.

myDBA.dev runs the same diagnostic, identifies the root cause, and generates:

-- Finding: autovacuum_enabled = false on orders table (dead tuples: 2.4M)
ALTER TABLE orders RESET (autovacuum_enabled);
-- Re-enables autovacuum with default settings

This pattern repeats across every domain. The tool does not just show you numbers -- it interprets them and produces the fix.

75+ Health Checks with Fix Scripts

pgwatch has no health check system. It collects metrics and displays them. Interpretation is left entirely 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 includes 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 -- scans, sizes, dead tuples. But it does not analyze your query workload and recommend new indexes or identify redundant ones.

myDBA.dev's index advisor examines your top queries, identifies sequential scans on large tables, detects duplicate and overlapping indexes, and generates CREATE INDEX or DROP INDEX CONCURRENTLY statements with estimated impact.

XID Wraparound Protection

pgwatch can show you XID age as a metric. You can set a Grafana alert when it crosses a threshold. But when XID wraparound is approaching, you need more than an alert -- you need to know which tables are the oldest, whether autovacuum is making progress, what is blocking it, and what emergency actions to take.

myDBA.dev detects XID wraparound risk, identifies the blocking factors (long-running transactions, prepared transactions, replication slots), and generates recovery scripts specific to your situation.

Extension Monitoring

pgwatch can store its own data in TimescaleDB, but it does not monitor TimescaleDB itself -- chunk health, compression ratios, continuous aggregate staleness, job failures, retention policies. It does not monitor pgvector index build progress, recall accuracy, or quantization overhead. It does not monitor PostGIS spatial index quality, SRID mismatches, or geometry validation.

myDBA.dev has dedicated monitoring for all three extensions with domain-specific health checks and remediation guidance.

EXPLAIN Plan Collection

pgwatch does not collect query execution plans. If a query suddenly slows down, you have metrics showing the change but no plan to diagnose why.

myDBA.dev automatically collects EXPLAIN plans for your top queries every collection cycle. When a query regresses, you can compare the old and new plans side by side to see whether the planner switched from an index scan to a sequential scan, whether row estimates drifted, or whether a new join strategy is suboptimal.

No Infrastructure to Manage

pgwatch requires you to deploy and maintain the collector, a PostgreSQL or TimescaleDB database for metrics storage, and Grafana for visualization. That is three services to keep running, updated, and backed up. For small teams, this operational overhead is real.

myDBA.dev is SaaS. Install a lightweight collector (a single Go binary), and everything else -- storage, dashboards, health checks, alerting -- is hosted.

Pricing Comparison

pgwatch: Free forever. BSD-3-Clause open source. You provide the infrastructure: a server for the collector, a database for metrics storage, and a Grafana instance. Ongoing cost is the compute, storage, and engineering time to maintain it all.

myDBA.dev: Free tier available with 7-day metric retention. Pro plan from GBP 19 per month with 30-day retention. No infrastructure to provision or maintain.

The real cost comparison is not license fees -- pgwatch wins that by definition. It is engineering time. If your team spends 4 hours per month maintaining Grafana dashboards, updating pgwatch, managing metrics storage, and manually interpreting alerts, that time has a cost too.

When to Choose pgwatch

• Your team has deep PostgreSQL expertise and prefers raw data over guided recommendations
• You already have a Grafana and Prometheus stack and want PostgreSQL monitoring to integrate natively
• You need custom business-domain metrics that only a SQL-based approach can provide
• Your budget for monitoring tools is zero and you have ops capacity to self-host
• You want full control over every aspect of your monitoring infrastructure
• Open-source licensing is a hard requirement

When to Choose myDBA.dev

• You want guided remediation, not just dashboards full of numbers
• Your team does not have a senior DBA who can interpret raw metrics and produce fix scripts
• You need extension monitoring for TimescaleDB, pgvector, or PostGIS
• You want EXPLAIN plan collection and automatic plan regression detection
• Health checks with prioritized, copy-pasteable fixes are more valuable to you than custom Grafana panels
• You do not want to manage monitoring infrastructure -- you want to manage your database

The Bottom Line

pgwatch and myDBA.dev solve different problems. pgwatch answers the question "what is happening in my database?" myDBA.dev answers "what is happening, what does it mean, and what should I do about it?"

If you have the expertise to bridge that gap yourself, pgwatch gives you excellent raw materials at zero cost. If you want the gap bridged for you with health checks, fix scripts, index recommendations, and extension monitoring, myDBA.dev does that work so you can focus on building your application.

Both are good choices. The right one depends on what your team needs most: data or direction.