Database Performance Correlation ties each application service to the database work it depends on inside the APM trace, so a slow transaction can be followed from the request through its API endpoint down to the specific database operation behind it.
Slow application transactions often trace back to the database calls behind them. Database Performance Correlation in Motadata ObserveOps ties each application service to the database work it depends on, so a slow trace reads as one connected story from the request down to the query.
Application Performance Monitoring (APM) instruments the application code and follows its database calls inside the trace, through a single unified MotaAgent built on OpenTelemetry standards. It reports on how the application talks to its databases, not on the health of the database host itself. Infrastructure-layer database host metrics such as CPU, memory, and storage stay with the Hybrid Infrastructure module and cross-link from here.
Motadata ObserveOps supports 40+ database systems. Whether a database was discovered through application instrumentation or through direct discovery, it links into APM traces and service topology, so visibility from application services to their database dependencies holds regardless of how the database was found.
This is APM's database performance monitoring layer: a trace-level view of database interaction, not a database-server monitoring tool in its own right. A slow query still reads through the application service that issued it.
Databases discovered directly, rather than through application instrumentation, link into APM traces and service topology. This closes a prior gap where directly discovered databases were isolated from APM correlation and read as standalone entities.
Correlation spans 40+ database systems supported by the platform, so a mixed data tier maps into the same trace and topology views without a separate tool per engine.
The APM Database tab filters database activity by operation type, including SELECT, INSERT, UPDATE, and DELETE, so read-heavy and write-heavy behavior can be isolated during an investigation.
Each application trace carries its database calls, so a transaction and the queries it triggers appear on one timeline and the dependency between service and database is explicit.
Correlated databases appear in the service topology alongside the services that call them, showing which application services depend on which data stores.
A single unified MotaAgent captures both the application trace and the database calls inside it, so service-to-database correlation does not depend on a second collector or a separate database agent.
Because database calls are attached to the trace behind an API endpoint, the API Endpoint Summary and its HTTP method filters narrow a database investigation down to the specific route generating the load.
Database dependencies for the services grouped into a named Business Service, such as Checkout, roll up alongside that Business Service's other application metrics, so a capability-level view still reaches down to its data layer.
Custom Reports in Chart, Grid, Top-N, Counter, and Aggregation formats can be built over correlated database activity, turning a recurring review of operation types or slow queries into a saved report.
10. Alerting when a service goes quiet:
A No Trace Received alert, configured during service registration, flags a database-dependent service when no traces arrive within a defined period, surfacing a broken integration before its database calls go unmonitored.
When P99 latency rises on a service, the linked database calls in the trace show whether the delay sits in application code or in the database interaction.
With 40+ database systems supported, teams review database interactions for many engines through the same APM views rather than switching tools.
Filtering the APM Database tab by SELECT, INSERT, UPDATE, or DELETE narrows an investigation to the operation class that matters for the incident at hand.
Because directly discovered databases correlate the same way instrumented ones do, coverage does not depend on how each database entered the platform.
Connected traces and topology mean an engineer moves from an affected service to its database dependency directly, without stitching separate views together by hand.
Because database correlation rolls up into Business Service views, a capability owner can see whether a data-tier problem is dragging down a named business function, not just an isolated service.
The single unified MotaAgent instruments application code and records the database calls each transaction makes as part of its distributed trace, built on OpenTelemetry standards. Java, .NET, PHP, Node.js, Python, and Go services report these calls across Host/VM, Docker, and Kubernetes. For Go, database tracing is not automatic: it requires QueryContext or ExecContext calls wrapped with the otelsql library.
For C++ and Ruby, database calls inside application traces are captured on Host/VM and Docker.
Directly discovered databases are collected as well and associated with the services that call them, regardless of instrumentation language.
Collected traces and database activity are analyzed so each service links to its database dependencies. The APM Database tab groups activity and filters it by operation type such as SELECT, INSERT, UPDATE, and DELETE, while service-level measures like P99 latency, error rate, and throughput frame where a transaction spends its time. A No Trace Received alert flags a database-dependent service that stops reporting.
Correlated data surfaces in APM traces, the APM Database tab, and the service topology, where databases sit beside the services that depend on them. An engineer follows one path from an application service through its trace, its API endpoint, and the Business Service it belongs to, down to the specific database operations behind a slow or failing request.
Database correlation follows the same footprint as the application traces it depends on. For Java, .NET, PHP, Node.js, Python, and Go, database calls are captured across Host/VM, Docker, and Kubernetes, including managed distributions on AWS EKS, Oracle OKE, Google GKE, and Rancher, plus serverless AWS EKS Fargate.
For C++ and Ruby, database calls inside traces are captured on Host/VM and Docker.
Because every environment shares the same single unified MotaAgent and OpenTelemetry foundation, a service's database dependencies read the same way whether it runs on a virtual machine, in a container, or across a cloud-native cluster, giving hybrid and cloud data tiers one consistent view rather than a separate tool per environment.
Database Performance Correlation reads the application side of the relationship: which service called which database, with which operation, inside which trace. It does not report on the database host's own CPU, memory, or storage; that is infrastructure-layer database monitoring and belongs to the Hybrid Infrastructure module, which cross-links from here for the host underneath a correlated database.
Keeping the two views separate matters during an incident. A slow trace with a heavy SELECT pattern points an engineer toward query or application-side behavior; a database host running short on memory or storage points toward Hybrid Infrastructure. ObserveOps links both without asking Database Performance Correlation to speak for the host it runs on.
Database Performance Correlation gives Motadata ObserveOps APM a continuous view from an application service to the database work it depends on. By linking both instrumented and directly discovered databases across 40+ database systems into traces and service topology, filtering database activity by operation type, and rolling that view up through API endpoints and Business Services, it lets teams find where a transaction slows down without leaving the application layer.
Discover how Motadata ObserveOps can help you monitor your infrastructure in real-time and respond to issues instantly.