obsdog

Database Monitoring

Database Monitoring (DBM) lets you identify slow queries, inspect execution plans, and correlate them with the resource state of the database host, all on one screen. It answers the question that collecting DB metrics or viewing queries in APM cannot reach: why is this query slow?

About 11 min read

What it does

Targeting self-hosted and managed versions of Postgres, MySQL, Oracle, SQL Server, MongoDB, Amazon DocumentDB, and ClickHouse, it collects and displays performance trends per normalized query (Query Metrics), individual execution samples (Query Samples), execution plans (Explain Plans), and the health of the database host along with recommendations for improvement. The Agent connects to the database and reads its statistics, so no code instrumentation on the application side is required.

When to use it

Use it in situations such as the application is slow but we cannot tell whether the database is to blame, RDS CPU is low but one specific screen is heavy, or we want to find the query that suddenly got slow last week. It is effective when a development team without a dedicated DBA needs to find slow queries on its own, or when comparing across multiple databases.

An everyday analogy

If database host metrics are the blood test in a health check-up, DBM adds an X-ray and a consultation on top. Beyond the abnormal number (high CPU), it also shows which part (the query) is generating the load and by what route (the execution plan).

How Is This Different from Just Collecting RDS Metrics?

When you collect metrics from RDS or your own Postgres through an integration, you can see the state of the database as a box: connection count, CPU, disk I/O, and so on. What you cannot see is which query inside that box is eating the time. Datadog's Database Monitoring (DBM) takes on this part; the official documentation describes it as a feature for isolating database problems by viewing historical query performance metrics, execution plans, and host-level metrics in one place (as of September 2026; source: Database Monitoring). Without it, an alert saying database CPU is high is followed by the work of connecting to the database and reading the statistics views by hand. With it, slow queries and their share of time are lined up in a list, and you can cross-check what was running at that moment against the CPU graph from Infrastructure Monitoring on the same time axis.

Among the DBM screens, three are central to tracking queries. Query Metrics shows performance over time per normalized query (queries of the same shape with parameter differences collapsed), identifies the queries that consume the most time, and can be narrowed along any axis such as team, cluster, or host. Query Samples shows the queries that were actually running at a given time, compares each execution against the average to find rare but extremely slow executions and outliers, and attributes them to a user, application, or client host. Explain Plans shows the database's execution plan step by step, letting you track high-cost operations such as sequential scans over large tables and how plans change over time (as of September 2026; source: Database Monitoring).

The three DBM screens and the questions they answer (as of September 2026)
ScreenQuestion It AnswersSuited Situation
Query MetricsWhich query has been taking up how much time, and since whenWeekly trend review, threshold alerts
Query SamplesWhat was running at that instant, and which execution deviated from the averageReconstructing the time of an incident, hunting rare slow executions
Explain PlansHow the database tried to execute that queryIdentifying missing indexes and sequential scans
Source: organized from the Explore section of Database Monitoring

In addition, there is the Databases page listing database hosts, the Recommendations page presenting improvement opportunities in priority order, and custom_queries for collecting business indicators from your own tables.

Supported Databases and Hosting Types

Seven database families are supported: Postgres, MySQL, Oracle, SQL Server, MongoDB, Amazon DocumentDB, and ClickHouse, each covering both self-hosted and managed cloud versions (as of September 2026; source: Database Monitoring). The setup guides are split by combination of database and hosting type; taking Postgres as an example, supported versions run from 9.6 through 18, and the hosting options listed are eight: self-hosted, Amazon RDS, Amazon Aurora, Google Cloud SQL, Google AlloyDB, Azure, Heroku, and Supabase (as of September 2026; source: Setting up Postgres).

Databases supported by DBM and the hosting types listed on the entry pages (as of September 2026)
DatabaseHosting Types Listed on the Entry Page
PostgresSelf-hosted / RDS / Aurora / Cloud SQL / AlloyDB / Azure / Heroku / Supabase
MySQLSelf-hosted / RDS / Aurora / Cloud SQL / Azure
OracleSelf-hosted / RDS / RAC / Exadata / Autonomous Database
SQL ServerSelf-hosted / RDS / Azure / Cloud SQL
MongoDBSelf-hosted / MongoDB Atlas
Amazon DocumentDBAmazon DocumentDB
ClickHouseSelf-hosted / ClickHouse Cloud
Source: Database Monitoring and Setting up Postgres (as of September 2026)

Even if your database is not in this table, metric collection through an integration may be provided separately, so check the two independently.

How the Role Differs from Query Display in APM

If you have APM installed, queries to the database appear inside traces as spans, and you can see how many milliseconds each query took. So why is DBM needed separately? What APM sees is the wait time as observed from the application side; what happened inside the database is not captured. The official documentation also states that Query Metrics shows database-level indicators that APM does not capture, such as rows updated and rows returned (as of September 2026; source: Database Monitoring). Conversely, with DBM alone, which service called a given query can only be inferred from information on the database side. The host detail view on the Databases page shows the calling services, so the working pattern is to go back and forth: application to database with APM, database to application with DBM. Billing is also separate, with APM based on hosts and span volume and DBM on database hosts, so if you are at the stage of chasing only database slowness, putting DBM in first is a legitimate choice.

Billing Is per Database Host - with an Allotment of 200 Normalized Queries

The billing unit is the database host. The Datadog pricing page shows, as a monthly amount per database host, an annual-contract unit price and higher monthly and on-demand unit prices, and each host comes with an allotment of 200 normalized queries (source: Datadog Pricing). A normalized query groups together queries of the same shape that differ only in parameters, and the official billing documentation states that there is billing based on the total number of normalized queries configured for tracking (as of September 2026; source: Pricing (Billing)). Database hosts are counted by recording the number of unique hosts under monitoring every hour, the same method as for hosts in Infrastructure Monitoring. The point to note is that database hosts are counted separately from the hosts your application runs on, so even if you already have an Infrastructure Monitoring contract, the number of databases you bring under DBM is added on top. For how to read the SKU as a whole, see how to read the pricing structure. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

What Is Required to Enable It

There are two prerequisites. One is that you have an Infrastructure Monitoring contract and have the standard Datadog Agent installed. The FAQ on the pricing page answers that DBM can be used in that state (as of August 2026; source: Datadog Pricing). The other is configuration on the database side; the procedure in the official documentation consists of two stages, configure the database and install the Agent, with a separate guide for each combination of database and hosting type (as of September 2026; source: Database Monitoring). Because the Agent connects to the database and reads its statistics, no instrumentation that touches the application code is required. Since the database-side configuration follows the guide for each database, agreeing with the database administrator in advance on what the Agent will read keeps the rollout from stalling. Query parameters are obfuscated on the Agent side, and the pricing page lists automatic obfuscation of personal information from all query data as a feature.

The Order for Identifying a Slow Query

To get the most out of DBM, deciding in advance on an order that descends from application-side slowness to database-side waits to execution plans keeps you from getting lost.

  • 1. On the APM service page, identify which endpoint is slow
  • 2. Look at the database spans in that trace and confirm that most of the wait time is on the database side
  • 3. In DBM Query Metrics, open the time trend for the corresponding normalized query and see when it became slow
  • 4. In Query Samples, compare the executions at the time of the incident against the average and confirm the caller of the outlying executions
  • 5. In Explain Plans, check for sequential scans and plan changes, and draft proposals for indexes or rewrites
  • 6. On the Databases page, look at blocking queries and host resources to judge whether it is a database-wide problem or a single-query problem
Isolation order for slow queries (the author's arrangement mapping DBM and APM screens to each other)

There are two key points to this order. One is not to start from the database side. Even if database CPU is high, an investigation that does not connect to the endpoint users perceive as slow gets its priorities wrong. The other is to look at execution plans last. Plans give you the answer, but if you open them before deciding which query to fix, the amount you have to read balloons. If you narrow down in the order of who is suffering, which query, and why it is slow, the three DBM screens map directly onto the three stages of the investigation.

Things to watch out for

  • This article is based on the official documentation as of September 2026. Supported databases and versions may be added or discontinued, so check the compatibility table on the setup page for each database when deploying.
  • This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.
  • For how database hosts are counted and the normalized query allotment, see the billing section in the body.
Share

Related products

Infrastructure MonitoringInfrastructure Monitoring is the product that visualizes the state of servers, containers, and cloud resources at the host level. The host map and process list let you grasp at a glance which host is struggling right now.APMA product that follows each individual request your application receives and visualizes where the time went as a trace.IntegrationsIntegrations are the bundle of entry points that pour data from external systems such as AWS and MySQL into Datadog. Where you configure them splits into two families, the Agent side and the cloud account side, and which one you choose changes both what you can see and how billing is counted.Datadog AgentSoftware that runs resident on the servers and containers you monitor and delivers metrics, logs, and traces to Datadog.Continuous ProfilerA profiler that breaks down the CPU and memory of an application running continuously in production, down to which function is using how much. You use it to chase the cause of a slow endpoint found in a trace all the way down to the line of code.

Related integrations

MongoDB integration metrics328 metricsMySQL integration metrics255 metricsOracle Database integration metrics88 metricsPostgres integration metrics244 metricsSQL Server integration metrics162 metrics

Products in the same category

Container MonitoringA mechanism for following containers that are born and gone within seconds and keep moving between nodes, with the same hands-on approach as host monitoring. On Kubernetes, how the Agent is placed and how billing is counted are both specific to containers, so we cover those two points first.Infrastructure MonitoringInfrastructure Monitoring is the product that visualizes the state of servers, containers, and cloud resources at the host level. The host map and process list let you grasp at a glance which host is struggling right now.Network MonitoringA group of features for finding failures that happen not inside a server but "between servers." With two pillars, CNM, which follows traffic flows on the cloud side, and NDM, which watches routers and switches via SNMP, it fills the blind spot of host monitoring.Process MonitoringA feature (Live Processes) for identifying the processes consuming a host's CPU and memory. It goes one level below host monitoring and lets you track who is using resources without logging in to the server.Serverless MonitoringMonitoring that watches execution environments with no resident host, such as AWS Lambda, using function invocations as the unit. The Lambda Extension sends metrics, traces, and logs from inside the function, and Cloud Run and Azure apps are viewed in the same frame.

Similar articles / products

Service (APM)In APM, a service is the name given to a set of processes that do the same job, and it is the first unit at which Datadog APM bundles traces and aggregates performance. An API with a group of endpoints or a database with a group of queries becomes a single service, and the name is determined by the instrumentation configuration.Resource (APM)An APM resource is the unit in Datadog APM that represents a specific operation within a service; for a web service it is an endpoint, for a database service a normalized query, and otherwise a background job. Spans with the same resource name are aggregated, and the resource becomes the axis for reading trends.SpanA unit that records when a single piece of work within a process started and when it ended. These units nest and stack up into a single trace, so how finely you can pinpoint the cause of slowness is decided by how you capture spans.Datadog vs Azure Monitor - Dividing Roles with the Built-in MonitoringIf you use Azure, Azure Monitor is already in your hands. So where is the reason to add Datadog? This article organizes the conditions for dividing roles using only primary official sources from both sides: Azure Monitor's coverage and billing structure, how Datadog sees Azure, and a configuration that avoids paying both.