(opens in a new tab)

Datadog DBM Alternatives: 9 Tools Compared

September 16, 2026 by Chat2DB Team

Datadog Database Monitoring (DBM) is a good product that a lot of teams buy for the wrong reason. They already have the Datadog Agent everywhere, a database gets slow, someone flips DBM on, and three months later finance asks why the bill moved. Meanwhile the thing the team actually needed was the ability to look at one slow query, read its plan, and ship a better version of it.

This article is about that gap. It covers what Datadog DBM genuinely gives you, the specific reasons teams start searching for Datadog DBM alternatives, and a ranked list of what to use instead — including the free SQL that reproduces a large share of the DBM dashboard on any PostgreSQL or MySQL instance you can connect to.

If you want a broader survey rather than a Datadog-centric one, we also maintain a general guide to the best database monitoring tools.

What Datadog Database Monitoring actually gives you

DBM is a separate product from Datadog APM and Datadog Infrastructure, sold as its own module and enabled per database host. Once it is running against PostgreSQL, MySQL, SQL Server or Oracle, you get:

• Normalized query metrics. Statements are fingerprinted so that a thousand variations of the same SELECT collapse into one row, with calls, total time, rows and I/O tracked over time.
• Sampled execution plans. DBM periodically captures EXPLAIN output for expensive statements, so you can see which plan a query was running when it regressed rather than the plan it would get today.
• Active session history. A continuous sample of what every backend is doing and what it is waiting on, which is how you tell an I/O problem from a lock convoy.
• Blocking and lock chains. Who is holding what, and who is queued behind them.
• Correlation with the rest of Datadog. This is the real differentiator. A slow checkout trace in APM links to the exact database statement, which links to the host metrics and logs for the machine it ran on. Nothing else on this list does that as smoothly.

That last point is worth paying for if you already live in Datadog. The question is whether you do.

Why teams look for Datadog DBM alternatives

The billing model stacks

DBM is priced per monitored database host and is billed on top of infrastructure monitoring for those same hosts — you are generally paying for the host twice, once as infrastructure and once as a database. Add APM, custom metrics and log ingestion on the same machines and the per-database cost becomes hard to predict, particularly on ephemeral or autoscaled fleets where host counts move.

None of that makes it bad value if you use the correlation. It does mean that a team monitoring a dozen database replicas purely to see slow queries is buying a platform to get a feature. Check the current rate card on Datadog's pricing page before modelling anything; the shape of the model matters more than the number, and the shape is per-host and additive.

Setup is not just "install the agent"

DBM is not a checkbox on an existing Agent install. For PostgreSQL you create a dedicated monitoring user, grant it pg_monitor, install pg_stat_statements, and create a schema with an explain_statement function that the Agent calls to collect plans. MySQL needs performance_schema consumers enabled and a similar grant set. On managed services — RDS, Cloud SQL, Aurora — you also need parameter-group changes and a restart in some cases.

It is all documented and none of it is hard, but it is a change-controlled task on every instance, and it is the step where DBM evaluations most often stall.

It is a lot of product if you only need query insight

A meaningful number of teams turn on DBM because one endpoint is slow. What they need is: which statement, what plan, which index. That is a workbench problem, not an observability-platform problem. Buying per-host monitoring to answer it is like buying a CT scanner to find your car keys.

The best Datadog DBM alternatives, ranked

1. Chat2DB — for actually fixing the query

Be clear about what this is: Chat2DB (opens in a new tab) is an AI database client and SQL workbench, not an APM product. It does not install an agent on your hosts, does not collect time-series metrics, and will not page you at 3am. Nobody should replace Datadog DBM with it if what they need is continuous host-level monitoring and alerting.

It is ranked first anyway, because the step that follows every DBM alert is the one most teams handle worst. A monitor hands you a query fingerprint and a plan snapshot, and then you need somewhere to open that query against the real schema, check whether the index you are about to add already exists under a different name, run EXPLAIN (ANALYZE, BUFFERS) on a modified version, and compare the two plans. Chat2DB is that place: it connects to PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, ClickHouse and 20+ other engines, renders execution plans as a readable tree, explains in plain language why a plan is slow, and generates or rewrites SQL from a description of the schema.

Used properly it is the other half of a monitoring stack rather than a replacement for one — pair it with the free SQL later in this article, or with pgwatch or PMM, and many teams find they never needed the per-host product. There is a desktop client and a browser version at app.chat2db.ai (opens in a new tab) if you would rather not install anything.

Good at: investigation, plan reading, query rewriting, schema exploration, multi-engine work in one window. Not: agent-based host monitoring, alerting, metric retention, APM correlation. Suits: engineers and DBAs who need to diagnose and fix, and small teams who want their monitoring budget to stay at zero.

2. pganalyze — for PostgreSQL depth Datadog does not reach

PostgreSQL only, and it goes deeper on PostgreSQL than any generalist can. Plan change detection over time, an index advisor that shows its reasoning rather than just naming columns, detailed vacuum and bloat tracking, buffer cache analysis, log-based insight into checkpoints and autovacuum behaviour. SaaS or self-hosted with an on-premise collector so query text never leaves your network.

Good at: being the best PostgreSQL analysis tool available. Not: multi-engine — it does nothing for your MySQL or Mongo instances — and it is a commercial, per-server product. Suits: teams whose critical workload is PostgreSQL and who want more than DBM gives them, not less.

3. Percona Monitoring and Management (PMM) — the free multi-engine replacement

Open source, no licence cost, covering PostgreSQL, MySQL, MariaDB and MongoDB. Query Analytics is the closest free equivalent to DBM's query view: normalized fingerprints, per-query metrics over time, plan capture, and filtering by host, schema or user. It is built on Prometheus/VictoriaMetrics and Grafana but packaged so you do not assemble it yourself, and the dashboards carry a lot of Percona's tuning knowledge.

Good at: being a genuine functional substitute for DBM's database half, at no licence cost. Not: correlated with your application traces, and the server is real infrastructure you have to run, upgrade and back up. Suits: mixed-engine shops with operational capacity and a preference for spending engineer time over vendor money.

4. SolarWinds Database Performance Analyzer (DPA) — wait-time analysis

DPA's organizing idea is wait time: for every statement it shows what the database was blocked on, broken down by wait type, over any window you choose. That framing separates "this query needs an index" from "the storage is saturated" from "this is a locking problem" faster than a metrics dashboard does. Engine support is unusually broad and includes Oracle, SQL Server, DB2, PostgreSQL, MySQL and SAP ASE.

Good at: diagnosing why time was spent, across legacy commercial engines DBM covers thinly or not at all. Not: modern-feeling. The UI shows its age, and licensing is per monitored instance. Suits: enterprises with heterogeneous estates and DBAs who already think in wait events.

5. Redgate Monitor — for SQL Server estates

Formerly SQL Monitor, and still the strongest option if SQL Server is your centre of gravity. Deep engine integration, deadlock analysis, sensible alerts out of the box, long metric retention, estate-wide views, plus PostgreSQL and other platform coverage in recent versions.

Good at: SQL Server, including the parts generic tools skip. Not: the best choice for a PostgreSQL-first or MySQL-first team. Suits: Microsoft-centric organizations, especially regulated ones that want it self-hosted.

6. New Relic — the closest like-for-like swap

The same positioning as Datadog: full-stack observability with database performance correlated to traces. Worth evaluating specifically because the commercial model is structured differently — oriented around data ingest and user seats rather than per-host SKUs — which can change the arithmetic for a fleet with many small database instances. Verify current terms directly with the vendor; both companies revise them.

Good at: APM correlation, for teams who want that but dislike Datadog's host-based model. Not: deeper than DBM on database internals. You are changing the billing shape, not the capability tier. Suits: teams already standardized on New Relic, or actively re-tendering their observability contract.

7. Grafana with Prometheus exporters — build it yourself

postgres_exporter or mysqld_exporter scraping into Prometheus, dashboards in Grafana, alerting via Alertmanager. If you already run this stack for everything else, adding databases costs you a scrape config and a dashboard import. postgres_exporter will also run custom queries you define in YAML, which is how you get pg_stat_statements data into Prometheus.

Good at: cost, control, and fitting the tooling you already operate. Not: query-level analysis out of the box. Exporters export metrics; there is no fingerprinted query view, no sampled plan history, and high-cardinality query text is a poor fit for Prometheus in the first place. Suits: infrastructure teams with an existing Prometheus estate who want database metrics beside everything else, and who will use a client like Chat2DB for the per-query work.

8. pgwatch — lighter self-hosted PostgreSQL monitoring

Open-source PostgreSQL monitoring with a configurable metrics collector, prebuilt Grafana dashboards, and a choice of storage backends including PostgreSQL, TimescaleDB and Prometheus. Considerably less to operate than PMM if PostgreSQL is all you run.

Good at: self-hosted PostgreSQL metrics with a small footprint and flexible collection intervals. Not: as polished or as widely deployed as the commercial options; you own the dashboards you customize. Suits: PostgreSQL-only teams who want history and alerting without standing up a full observability platform.

9. The free built-ins — start here before buying anything

Every engine ships with most of what a monitoring product visualizes. PostgreSQL has pg_stat_statements, pg_stat_activity, pg_locks and the pg_stat_* family; MySQL has performance_schema and the sys schema; RDS and Aurora users already have Performance Insights with database load broken down by wait event and top SQL, enabled with one setting. What you lack is retention, alerting and a UI — and if you are being honest about the incident you are trying to prevent, sometimes that is fine.

The next section is the SQL.

The free SQL that covers most of what DBM shows you

Run these from any client. Each one maps to a panel you would otherwise pay per host to see.

PostgreSQL: top statements by total time

This is the single most valuable query in the article, and it is the same data DBM's query view is built on. Enable the extension first:

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

SELECT substring(query, 1, 90)                            AS query,
       calls,
       round(total_exec_time::numeric, 0)                 AS total_ms,
       round(mean_exec_time::numeric, 2)                  AS mean_ms,
       round(100 * total_exec_time
             / nullif(sum(total_exec_time) OVER (), 0), 1) AS pct_of_total,
       rows / nullif(calls, 0)                            AS rows_per_call,
       shared_blks_read                                   AS disk_blocks_read
FROM pg_stat_statements
WHERE query NOT LIKE '%pg_stat_statements%'
ORDER BY total_exec_time DESC
LIMIT 20;

Read the pct_of_total column, not mean_ms. Database time is a budget, and the query spending the most of it is frequently a fast statement executed enormously often rather than the report everyone complains about. Call pg_stat_statements_reset() at the start of a window if you want to measure a specific period instead of everything since the last restart.

PostgreSQL: cache hit ratio

SELECT datname,
       blks_hit,
       blks_read,
       round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS cache_hit_pct
FROM pg_stat_database
WHERE datname = current_database();

For an OLTP workload this should sit above 99%. A sustained drop means the working set no longer fits in shared_buffers plus the OS page cache — either the data grew, or a new query is scanning something large. Cross-check against disk_blocks_read in the previous query to find the culprit.

PostgreSQL: index usage and dead weight

Tables taking sequential scans they should not:

SELECT relname,
       seq_scan,
       seq_tup_read / nullif(seq_scan, 0) AS avg_rows_per_seq_scan,
       idx_scan,
       n_live_tup
FROM pg_stat_user_tables
WHERE n_live_tup > 10000
  AND seq_scan > coalesce(idx_scan, 0)
ORDER BY seq_tup_read DESC
LIMIT 20;

And indexes that cost you write throughput while returning nothing:

SELECT s.relname AS table_name,
       s.indexrelname AS index_name,
       s.idx_scan,
       pg_size_pretty(pg_relation_size(s.indexrelid)) AS index_size
FROM pg_stat_user_indexes s
JOIN pg_index i ON i.indexrelid = s.indexrelid
WHERE s.idx_scan = 0
  AND NOT i.indisunique
  AND NOT i.indisprimary
ORDER BY pg_relation_size(s.indexrelid) DESC;

Before dropping anything, confirm the counters have been accumulating since well before the last pg_stat_reset() and that no quarterly job depends on the index.

PostgreSQL: blocked sessions

The query to run when the application has stopped responding and you have thirty seconds to explain why:

SELECT blocked.pid                          AS blocked_pid,
       blocked.usename                      AS blocked_user,
       now() - blocked.query_start          AS blocked_for,
       substring(blocked.query, 1, 70)      AS blocked_query,
       blocking.pid                         AS blocking_pid,
       blocking.state                       AS blocking_state,
       substring(blocking.query, 1, 70)     AS blocking_query
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
ORDER BY blocked_for DESC;

Add pg_locks when you need the lock mode and object rather than just the chain:

SELECT l.pid, l.locktype, l.mode, l.granted,
       relation::regclass AS relation,
       substring(a.query, 1, 70) AS query
FROM pg_locks l
LEFT JOIN pg_stat_activity a ON a.pid = l.pid
WHERE NOT l.granted
ORDER BY l.pid;

A blocking session sitting in idle in transaction is the classic finding: some application code opened a transaction, took a row lock, and went off to call an HTTP API.

MySQL: the performance_schema equivalents

The digest table is MySQL's pg_stat_statements. Timers are in picoseconds, hence the divisors:

SELECT LEFT(DIGEST_TEXT, 90)                          AS query,
       COUNT_STAR                                     AS calls,
       ROUND(SUM_TIMER_WAIT / 1000000000000, 2)       AS total_sec,
       ROUND(AVG_TIMER_WAIT / 1000000000, 2)          AS avg_ms,
       SUM_ROWS_EXAMINED / NULLIF(COUNT_STAR, 0)      AS rows_examined_per_call,
       SUM_ROWS_SENT / NULLIF(COUNT_STAR, 0)          AS rows_sent_per_call,
       SUM_NO_INDEX_USED                              AS no_index_used
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;

The ratio of rows_examined_per_call to rows_sent_per_call is the tell. Examining 500,000 rows to return 10 is a missing or unusable index almost every time, and no_index_used confirms it. Reset the window with TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;.

If statement digests are empty, the consumers are off:

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE 'events_statements%';

InnoDB buffer pool hit ratio, the MySQL analogue of the cache hit query:

SELECT ROUND(100 * (1 - (
         (SELECT VARIABLE_VALUE FROM performance_schema.global_status
          WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads')
         /
         (SELECT VARIABLE_VALUE FROM performance_schema.global_status
          WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')
       )), 2) AS buffer_pool_hit_pct;

Tables being scanned without indexes, straight from the sys schema:

SELECT * FROM sys.schema_tables_with_full_table_scans LIMIT 20;
SELECT * FROM sys.schema_unused_indexes;

And the blocking view, which is the direct counterpart of the PostgreSQL query above — it even hands you the statement that clears the jam:

SELECT wait_age,
       locked_table,
       locked_index,
       waiting_pid,
       waiting_query,
       blocking_pid,
       blocking_query,
       sql_kill_blocking_query
FROM sys.innodb_lock_waits
ORDER BY wait_age DESC;

Between these, a scheduled job that snapshots the digest and statement tables every few minutes, and a client to investigate the results, you have reproduced the substance of a DBM query dashboard. What you have not reproduced is retention, anomaly detection, alert routing and trace correlation — which is exactly the honest list of what you are buying when you pay for a platform.

How to choose

Three rules that hold regardless of the choice. Enable pg_stat_statements or performance_schema digests before you evaluate anything, because every product on this list reads from them and a trial against uninstrumented databases tells you nothing. Separate monitoring from investigation — the tool that notices a problem is rarely the tool that fixes it, and paying a monitoring vendor to do a workbench's job is how the per-host bill grows. Alert on symptoms, not thresholds: replication lag above a minute, connections above 85% of max_connections, a session blocked longer than 30 seconds and transaction ID age above 200 million are all worth waking someone for. CPU above 80% during the nightly batch is not.

Summary

Datadog DBM earns its place when you need database performance stitched into application traces and host telemetry, and you should keep it if you use that. Teams leave it for three predictable reasons: it is billed per database host on top of infrastructure monitoring, enabling it means a per-instance grant-and-extension exercise, and it is far more platform than a team needs if the real requirement is fixing a handful of slow queries. Alternatives sort cleanly by intent — pganalyze for PostgreSQL depth, PMM for free multi-engine coverage, DPA for wait analysis, Redgate for SQL Server, New Relic for a different billing shape, exporters or pgwatch for self-hosted, and the built-in catalogs for free. Start with the SQL in this article, add Chat2DB (opens in a new tab) to read the plans and rewrite the queries it surfaces, and buy a monitoring platform only for the capability the free path genuinely cannot give you: retention, alerting and correlation.