Database query monitoring in Services
- Latest Dynatrace
- Explanation
- 7-min read
- Published Aug 20, 2026
In Dynatrace, every database call a service makes is captured as a span and reflected in the service's performance data. This page explains how Dynatrace models database dependencies and where to find database data in your environment.
Overview
When a service makes a database call, Dynatrace captures it as a database client span. These spans carry specific semantic attributes that power database-related views in Dynatrace apps.
Dynatrace treats the service as the primary observability entity because it's the service where the performance impact of a slow database query is noticeable, and correlating database behavior to service health is the primary use case. The database appears as a dependency of the calling service.
Related Dynatrace apps
Several Dynatrace apps cover the database monitoring experience.
Services
- All databases a service communicates with
- Database query performance
- Databases in the service topology, represented by the Service Map
Databases
- Admin view of database instances
- Database-centric alerting and deep metrics
Clouds
- Details on cloud databases
Database data sources and representations
The database experience in Services draws on three data representations: span attributes, the dt.service.database.query.count metric derived from those same spans, and Smartscape traversal for monitored databases.
Span attributes
Every database call generates a database client span that carries the following attributes:
db.system: Database technology (for example,postgresql,mysql, ordynamodb)db.namespace: Database name (for example,ordersorinventory)db.query.text: SQL statement or command (for example,SELECT * FROM orders WHERE id = ?)
These span data drive the Database queries view in Services, which shows individual queries with their query count, duration, and error rate.
Rely on these span attributes to query database data with DQL, for example, to analyze database query performance or track call volume by database entity.
dt.service.database.query.count metric
The dt.service.database.query.count Grail-powered metric is produced automatically alongside span ingestion and tracks database entities a service communicates with. For monitored databases, Dynatrace maintains a topology-linked database entity, and the dt.service.database.query.count metric includes that entity ID.
In Services, the dt.service.database.query.count metric defines the edge between the service node and the database node in the Service Map.
Use the dt.service.database.query.count metric to analyze the query volume of your services and to find unmonitored databases.
Smartscape traversal
When a database is monitored and has a linked Smartscape node, Dynatrace also records the service-to-database relationship in Smartscape on Grail.
The Smartscape traversal approach complements the metric-based approach. While the dt.service.database.query.count metric covers all databases, including unmonitored databases identified only from spans, Smartscape gives you a richer context for monitored databases.
Rely on the Smartscape traversal to query relationships directly, without relying only on span or metric data. For example, you can retrieve all database entities to which a particular service is connected (check the Find services calling AWS RDS databases query example). For Smartscape relationship types and query examples, see Explore the service entity in Smartscape on Grail.
Database monitoring methods
Dynatrace can monitor databases in different ways.
Cloud databases are monitored via cloud monitoring. More traditional databases, like Oracle or Microsoft SQL Server, are monitored via Dynatrace database extensions, for example, Oracle Database or Microsoft SQL Server.
For such monitored databases, a linked Smartscape node is available, and you can navigate from the Service Map in Services to Clouds or Databases for more detailed information about these databases.
The Service Map in Services also shows unmonitored databases that are used by your services. To learn how to identify unmonitored databases, see Discover and onboard unmonitored databases with Service Map.
Segments and database data
In Services, segments apply to database data the same way they apply to service data. The dt.service.database.* metrics belong to the calling service and share its primary Grail fields, primary Grail tags, and security context.
When you filter by segments in Services, the Database queries view and the Service Map show only the databases and queries called by services that match the segment. For example, a segment scoped to a specific Kubernetes namespace limits the visible database dependencies to services within that scope.
Access to database data follows the same security context as the calling service: if you have access to a service, you have access to its database queries and dependencies.
Use cases
For the use cases related to database monitoring, see Investigate database performance and dependencies in Services.