(opens in a new tab)

9 Best Database Monitoring Tools in 2026

August 16, 2026 by Chat2DB Team

Infrastructure monitoring tells you the database server is using 90% CPU. Database monitoring tells you which query is responsible, how its plan changed last Tuesday, and which index would fix it. The second question is the one you actually need answered at 3am, and generic APM tools rarely answer it well.

This guide covers the tools worth evaluating in 2026, what each is genuinely good at, and — since a surprising amount of this is available for free — the SQL to monitor PostgreSQL without buying anything.

What database monitoring should cover

Before comparing tools, it helps to be clear about what separates real database monitoring from a CPU graph:

• Query-level performance — which statements consume the most total time, not just the slowest single execution. A 5 ms query running 200,000 times an hour costs more than a 20-second report.
• Execution plan history — plans change when statistics shift, and a query that regressed overnight almost always regressed because of a plan flip.
• Wait events — whether time is spent on CPU, I/O, locks or latches. This is the difference between "add an index" and "the disk is saturated".
• Locking and blocking — which session is holding what, and who is queued behind it.
• Replication lag — how far behind standbys are, in bytes and in seconds.
• Vacuum and bloat (PostgreSQL) or buffer pool health (MySQL) — the maintenance metrics that predict problems days ahead.
• Connection saturation — how close you are to max_connections, and how many connections sit idle in transaction.

A tool that only reports the first item is a slow query log with a dashboard.

Start here: what PostgreSQL gives you for free

Before evaluating anything, enable pg_stat_statements. It ships with PostgreSQL and is the foundation almost every commercial tool builds on.

-- postgresql.conf: shared_preload_libraries = 'pg_stat_statements'
-- then restart, and:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Find where your database actually spends its time:

SELECT substring(query, 1, 80) AS query,
       calls,
       round(total_exec_time::numeric, 1)          AS total_ms,
       round(mean_exec_time::numeric, 2)           AS mean_ms,
       round(100 * total_exec_time
             / sum(total_exec_time) OVER (), 1)    AS pct
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

That pct column is the one to read. It is common to find a single query accounting for 40% of database time, and it is rarely the one anyone suspected.

Cache hit ratio, which should sit above 99% for most workloads:

SELECT sum(heap_blks_hit) * 100.0
       / nullif(sum(heap_blks_hit) + sum(heap_blks_read), 0) AS cache_hit_pct
FROM pg_statio_user_tables;

Tables needing vacuum attention:

SELECT relname,
       n_live_tup,
       n_dead_tup,
       round(100.0 * n_dead_tup / nullif(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
       last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY dead_pct DESC NULLS LAST
LIMIT 20;

Sessions blocking other sessions — the query to run when everything has stopped:

SELECT blocked.pid          AS blocked_pid,
       blocked.query        AS blocked_query,
       blocking.pid         AS blocking_pid,
       blocking.query       AS blocking_query,
       blocking.state,
       now() - blocking.query_start AS blocking_duration
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking
  ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
WHERE cardinality(pg_blocking_pids(blocked.pid)) > 0;

And connections idle in transaction, a common cause of both connection exhaustion and vacuum stalling:

SELECT pid, usename, state,
       now() - state_change AS idle_duration,
       substring(query, 1, 60) AS last_query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND now() - state_change > interval '5 minutes'
ORDER BY idle_duration DESC;

These queries answer most incidents. What a monitoring tool adds is history — the ability to compare today against last week — and alerting so you find out before your users do.

The tools

pganalyze

PostgreSQL-only, and the depth shows. It tracks plan changes over time, surfaces the specific query that regressed, provides an index advisor that explains its reasoning rather than just suggesting columns, and reports vacuum, bloat and buffer cache behaviour in detail. Available as SaaS or self-hosted with an on-premise collector.

Best for: teams running PostgreSQL seriously who want the deepest analysis available. Trade-off: does nothing for your MySQL or MongoDB instances, and pricing is per server.

Percona Monitoring and Management (PMM)

Free and open source, covering PostgreSQL, MySQL, MariaDB and MongoDB. Built on Prometheus, VictoriaMetrics and Grafana, packaged so you do not have to assemble it yourself. Query Analytics gives per-query metrics with plan capture, and the dashboards encode a lot of Percona's tuning expertise.

Best for: mixed-engine environments, and anyone who wants strong monitoring with no licence cost. Trade-off: you run and maintain the server yourself, and it is a real component to operate.

Datadog Database Monitoring

Correlates database performance with application traces, host metrics and logs in one place. If a checkout endpoint slows down, you can follow it from the trace into the exact query and its plan. Supports PostgreSQL, MySQL, SQL Server, Oracle and MongoDB.

Best for: teams already using Datadog for APM and infrastructure. Trade-off: the cost model surprises people — per host, plus custom metrics, plus log ingestion. Model your spend before committing.

SolarWinds Database Performance Analyzer (DPA)

Built around wait-time analysis: for every query it shows what the database was waiting on, broken down by wait type. That framing is unusually good at distinguishing an I/O problem from a locking problem from a genuine CPU-bound query. Broad engine support including Oracle, SQL Server, DB2, PostgreSQL and MySQL.

Best for: mixed estates with legacy commercial databases, and DBAs who think in wait events. Trade-off: the interface shows its age, and licensing is per instance.

Redgate SQL Monitor

The strongest option in the SQL Server world. Deep integration with SQL Server internals, sensible built-in alerts, deadlock analysis and long metric retention, with growing PostgreSQL support.

Best for: Microsoft-centric shops. Trade-off: outside SQL Server, other tools are more capable.

Prometheus + Grafana with database exporters

The build-it-yourself option: postgres_exporter or mysqld_exporter scraping metrics into Prometheus, visualised in Grafana, alerting through Alertmanager. Free, entirely under your control, and it fits whatever you already run.

Best for: teams with existing Prometheus infrastructure and the appetite to maintain it. Trade-off: exporters give you metrics, not query-level analysis. Getting pg_stat_statements-quality insight requires additional work, and nobody hands you a plan history.

AWS Performance Insights

If you run RDS or Aurora, this is already there. Database load broken down by wait event and top SQL, with seven days of history free and longer retention paid. Enabling it takes one checkbox.

Best for: RDS and Aurora users who want useful monitoring immediately. Trade-off: AWS-only, and shallower than a dedicated tool — no index advisor, limited plan history.

pgwatch

Open-source PostgreSQL monitoring with a flexible metrics collector, Grafana dashboards and support for storing metrics in PostgreSQL, TimescaleDB or Prometheus. Lighter to run than PMM if PostgreSQL is all you have.

Best for: PostgreSQL-only teams wanting self-hosted monitoring without a large stack. Trade-off: smaller community and less polish than the commercial options.

New Relic Database Monitoring

Similar positioning to Datadog — database performance correlated with full-stack APM. The pricing model is different enough to be worth comparing directly, being based on data ingest and user seats rather than per host.

Best for: teams standardised on New Relic. Trade-off: database-specific depth trails the specialists.

Choosing

Two pieces of advice that apply regardless of which you pick.

Enable pg_stat_statements before anything else. Every PostgreSQL tool on this list reads from it, and it costs a few percent of overhead at most. Without it, you are buying a dashboard over data your database is not collecting.

Alert on symptoms, not thresholds. "CPU above 80%" fires constantly during normal batch windows and teaches everyone to ignore it. "Replication lag above 60 seconds", "connections above 85% of max", "a query blocked for more than 30 seconds", "transaction ID age above 200 million" — these correlate with actual problems and stay quiet otherwise.

Monitoring versus investigating

Worth separating two activities that get conflated. Monitoring is continuous and automated: collect metrics, retain history, alert on anomalies. Investigation is what you do once alerted — connect to the database, look at the schema, read the plan, test a fix.

Monitoring tools are generally poor at the second job. They show you the query but will not let you run a modified version against the real schema, check whether the index you are considering already exists, or compare the plan before and after. That is a SQL client's job.

Chat2DB (opens in a new tab) covers that investigation half: it connects to PostgreSQL, MySQL, SQL Server, Oracle, MongoDB and 20+ other databases, renders EXPLAIN output as a readable plan tree, and can describe in plain language what a plan is doing and why it is slow. There is also a web version (opens in a new tab) if you would rather not install anything. Pair it with a monitoring tool from the list above — one tells you when and what, the other helps you work out why.

Summary

Real database monitoring means query-level metrics, plan history, wait events, locking and replication lag — not just host CPU. Start with pg_stat_statements and the catalog queries above, which are free and answer most incidents. Then add pganalyze for PostgreSQL depth, Percona PMM for a free multi-engine option, Datadog or New Relic if you want database metrics correlated with application traces, Redgate for SQL Server, or Performance Insights if you are already on RDS. Whichever you choose, alert on symptoms that correlate with user impact rather than on resource thresholds that fire during every batch job.