Database Monitoring vs APM

Quick verdict

Database monitoring collects data from the database engine itself. Engines publish it through their own views: SQL Server's dynamic management views and Query Store, PostgreSQL's cumulative statistics views and pg_stat_statements, MySQL's Performance Schema. A database monitoring tool samples these on a schedule, keeps history and adds dashboards and alerts. Examples include Redgate Monitor, SolarWinds SQL Sentry and Database Performance Analyzer, Datadog Database Monitoring, and open source stacks built on Prometheus exporters.

APM (application performance monitoring) instruments the application. An agent or an OpenTelemetry SDK records each request as a trace made of spans: the incoming HTTP request, calls to other services, cache lookups and database queries. Each database span carries the duration seen by the application and attributes such as the database system and, where safe, the query text. Examples include Datadog APM, New Relic APM and open source tracing backends that accept OpenTelemetry data.

Both are part of what vendors call observability, and several platforms sell both. The difference is the vantage point: one looks out from the database at all its clients, the other looks out from one application at everything it calls.

Side by side

Key differences

What database monitoring sees: waits and query statistics

Database engines record why work is waiting. SQL Server's sys.dm_os_wait_stats returns aggregated information about all waits encountered by threads, cumulative since the last restart or reset; PostgreSQL's pg_stat_activity shows each backend's state and its current wait_event_type (such as Lock, LWLock, IO or Client) and wait_event. Query statistics come from Query Store and sys.dm_exec_query_stats on SQL Server, pg_stat_statements on PostgreSQL, and Performance Schema digests on MySQL. A monitoring tool samples these regularly so you can compare today with last week. Two baseline queries the tools build on:

-- SQL Server (T-SQL): top waits since the last restart or clear
SELECT TOP (10) wait_type, waiting_tasks_count,
       wait_time_ms, signal_wait_time_ms
FROM   sys.dm_os_wait_stats
ORDER  BY wait_time_ms DESC;

-- PostgreSQL: what active sessions are waiting on right now
SELECT pid, state, wait_event_type, wait_event, left(query, 60) AS query
FROM   pg_stat_activity
WHERE  wait_event IS NOT NULL AND state = 'active';

Microsoft notes that sys.dm_os_wait_stats needs VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later. In practice raw totals include many benign background waits, which tools filter out. Because this data comes from the server, it covers every workload: an overnight ETL job, a report someone runs from a desktop client, a deadlock between two services (see error 1205). None of that is visible to an APM agent in a single application.

What APM sees: requests, traces and spans

APM measures from the caller's side. The OpenTelemetry semantic conventions for database client spans, now marked stable, specify a CLIENT span whose duration should cover the whole call as the caller saw it, with attributes such as db.system.name, db.namespace, db.operation.name, a low-cardinality db.query.summary and, subject to sanitisation, db.query.text. The conventions say non-parameterised query text should not be collected by default unless sensitive literals are removed.

This view shows things the database cannot: that one page load runs the same query 200 times in a loop (the N+1 pattern), that most of a request's time is spent in an external API rather than the database, or that latency comes from connection pool waits in the application. New Relic's documentation, for example, describes slow query data sampled from transaction traces on its Databases page, with explain plans where supported. What APM cannot show is why the server took the time: whether the query waited on a lock held by another process, read from disk, or changed plan.

Where they overlap: query timing

Both report how long a query took, but the numbers differ. The database measures execution on the server; the application span also includes network round trips, driver work, fetching rows and, depending on instrumentation, time waiting for a pooled connection. A span of 900 ms for a query the server ran in 40 ms points away from the database; a span that matches the server time points into it. Neither number is wrong; they measure different intervals.

Some products now join the two. Datadog, for example, documents a DBM and APM connection that injects trace identifiers into queries as SQL comments, so a query sample in database monitoring links to the trace that issued it, and a trace span links to the query's explain plan; it supports Postgres, MySQL, SQL Server, Oracle and MongoDB. Without such a link, teams correlate by time, host and normalised query text.

Why teams combine them

A typical incident crosses both. APM raises an alert that checkout latency has doubled and shows the time is in one database span. Database monitoring shows that query is now waiting on locks held by a batch job that APM never saw, or that its plan changed after a statistics update. Each tool alone would leave half the story: APM would blame "the database", database monitoring would show a busy server without saying which users were affected.

In our view the order of investment depends on who owns the problem. Teams that write the application but use a managed database often start with APM and add database monitoring when database spans dominate. Teams that run shared databases for many applications start with database monitoring, because most load on the server is outside any one application's traces. See performance tuning for working with the plans both lead to.

Pricing and licensing

This is a conceptual comparison, so there is no single price; the billing units differ. Database monitoring products are commonly priced per monitored database instance or per database host: Datadog lists Database Monitoring per database host per month, separate from its APM and infrastructure products. APM is commonly priced per application host or by data volume: New Relic, for example, bills by data ingested per GB plus user licences across its platform. Built-in database views and open source stacks have no licence cost but need hosting and staff time. See the individual comparisons, such as Datadog vs New Relic and Prometheus vs Datadog, for dated prices.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You only need occasional PostgreSQL query analysis: the built-in pg_stat_statements view and a log analyser may be enough; see pgAdmin vs pgBadger.
• You run a single SQL Server and want a dedicated DBA tool rather than an observability platform: see Redgate Monitor vs SQL Sentry and Datadog vs Redgate Monitor.
• You want infrastructure metrics and alerting on a budget: see Prometheus vs Datadog.

Final recommendation

Frequently asked questions

Sources

• Microsoft Learn: sys.dm_os_wait_stats
• PostgreSQL documentation: The cumulative statistics system
• PostgreSQL documentation: pg_stat_statements
• OpenTelemetry: Semantic conventions for database client spans
• Datadog documentation: Database Monitoring
• Datadog documentation: Correlate DBM and APM
• New Relic documentation: View slow query details
• New Relic pricing

Checked October 2026.

How we research comparisons: our editorial method.