Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled.
Application performance monitoring (APM) provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it.
The application team may know where users are experiencing latency without knowing whether the cause is a blocked query, lock contention, an inefficient execution plan, resource competition, or another condition inside the database engine. Database observability helps close this diagnostic gap by providing the evidence needed to move from "the database is slow" to a specific, testable explanation.
The Gap Between Dependency and Diagnosis
Most production troubleshooting begins with the application because that is where the impact becomes visible. A checkout process takes too long, a billing transaction times out, or an API call exceeds its service-level objective. APM traces the request and may show that a database call accounts for much of the delay. It may not answer the next question: why did that call take so long?
Many APM and observability tools provide visibility into database dependencies, query calls, and response times. The depth available after that varies. Teams may still need database-native context to determine where execution time is being spent, which queries or sessions are involved, and whether the delay comes from blocking, contention, I/O, CPU pressure, or another wait condition.
Without that depth, investigation can become a series of handoffs between application teams, operations, and DBAs. This can lengthen incident resolution and make the response dependent on a small number of specialists. Database observability does not replace their expertise. It makes relevant diagnostic context easier to access and share across the incident team.
Why SAP HANA Is a Useful Example
SAP HANA often supports business-critical applications and a combination of transactional and analytical workloads. In an S/4HANA environment, database performance can directly affect order processing, billing, reporting, and other workflows.
When an application slows down, a high-level alert may show increased demand or resource pressure. It does not necessarily establish which workload is responsible or why a transaction is waiting. The consequences may include delayed transactions, missed service-level agreements, and longer investigations. The objective is not to label every slowdown a database problem, but to gather enough evidence to confirm or rule out the database quickly.
Moving From Symptoms to Wait-Based Evidence
Wait-based analytics is one of the clearest examples of the additional depth database observability can provide. A query does not spend all its time actively executing. It may also wait for a resource or another activity to complete. Wait-based analytics shows where that time is going and associates it with relevant queries, sessions, and conditions.
This helps teams distinguish between causes that may look similar from the application layer. A slow response could come from lock contention, storage latency, CPU pressure, competing workloads, or inefficient query behavior. Each may produce the same application symptom but require a different response.
CPU and memory metrics remain useful, but they do not always explain causation. High CPU might be a cause, a consequence, or normal behavior for the workload. Wait-based evidence adds context by showing how query execution time is being consumed.
For an application-focused reader, this is the difference between seeing that a database call added five seconds to a transaction and learning that a particular query spent most of those five seconds blocked by another session. The first observation identifies the affected dependency. The second provides a path toward root-cause analysis and mitigation.
It also gives application teams, operations, and DBAs a shared language. Instead of exchanging broad reports that "the app is slow" or "the database is busy," they can investigate a defined query, wait condition, session, and period of degradation.
In the future, AI may also play a role in deeper database observability and wait-based analytics. This could include reduction in some of the manual tasks associated with performance findings or guided investigation. It’s important to note, however, that any AI assistance must stay in a reporting role, with the underlying evidence guiding eventual mitigation.
Application Visibility and Database Depth Belong Together
The choice is not between APM and database observability. APM shows how a problem affects users, transactions, services, and dependencies. Database observability adds the depth needed to understand what is happening inside the database when it becomes part of the critical path.
This is why at SolarWinds we've worked to design tools, such as DPA for SAP HANA, that won't leave DBAs to spend hours guessing what happened. Together, APM and database observability create a clearer route from symptom to dependency, from dependency to cause, and from cause to mitigation. When the database is the problem, seeing that it is involved is only the beginning.
