Database monitoring approaches
- Latest Dynatrace
- Explanation
- Published Aug 26, 2026
Overview
Database monitoring in Dynatrace centers on the database instance, the running database engine. The host it runs on is a separate infrastructure layer that you monitor to complete the picture. This page explains both and how they fit together.
What is a database instance?
A database instance represents the running database engine you want to monitor, for example, an Oracle SID, a SQL Server named instance, or a PostgreSQL cluster. When you add a database through the Add DB instance wizard, Dynatrace creates a vendor-specific database instance entity DB_INSTANCE_*, for example DB_INSTANCE_POSTGRES, that tracks connection counts, buffer pool usage, active sessions, top queries, and execution plans for that engine.
What is a host?
A host is the physical or virtual machine where your database process runs. When OneAgent is installed on the host where the database runs, Dynatrace creates a HOST entity that represents the underlying infrastructure, including CPU utilization, memory consumption, disk I/O, and network throughput. Use the HOST entity to determine whether a performance issue originates from the database engine or the underlying host resources.
What you monitor with database monitoring
Enable a database extension for a DB_INSTANCE_* entity to collect engine-level data over a remote connection and view it in 
Databases. You can also use this data in dashboards, alerts, and notebooks.
Database monitoring provides:
- Engine metrics—Configuration, uptime, connections, buffer pools, activity, and query performance, collected from system tables to keep overhead low.
- Statement performance—The most resource-intensive SQL statements per instance. In the Statement performance analysis view, filter statements and rank them by Time, CPU, Disk, or Waits. Statements are normalized, so no personally identifiable information is stored.
- Execution plans—Request a plan for any statement to see how the engine runs the query and why it's slow. Dynatrace fetches plans automatically for PostgreSQL and MySQL, and on demand for Oracle and MySQL.
- Availability—Reachability of the database endpoint.
- Vendor-specific metrics—The metric set depends on the feature sets you enable.
Dynatrace stores this data in the default_database_monitoring Grail bucket and retains it for 35 days by default. For the metrics available per vendor, see Data collected with Dynatrace database monitoring.
What host monitoring covers
Host monitoring covers the infrastructure the database runs on, not the database engine. It reports OS-level metrics, including CPU, memory, disk, and network for that machine, and doesn't require polling the database itself:
- On a host you control, install OneAgent on the machine. Dynatrace then represents it as a
HOSTentity and reports its OS-level metrics. - For cloud-hosted or fully managed databases, host and OS metrics come from the cloud provider's monitoring service instead.
Use host monitoring for on-premises or self-managed databases where you want visibility into the underlying infrastructure alongside the database engine.
Combine database and host monitoring
We recommend combining database monitoring with host monitoring, or cloud monitoring for cloud-hosted databases, to gain a complete view of your databases and the infrastructure they run on. For example, you can install OneAgent on a self-managed PostgreSQL host to enable full-stack observability and configure a database instance through the extension to collect additional engine metrics and query insights.
When both are configured, Databases displays the DB_INSTANCE_* and HOST entities together. This view helps you correlate database engine health with the underlying infrastructure and determine whether a performance issue originates from the database engine or the host resources.
Databases