Analyze database and instance-level performance issues

When you are part of a development, operations, or devops team, database issues need to be investigated quickly. To resolve performance problems and errors with a slow or failing app, you need to be able to analyze whether the underlying cause is related to database performance, one or more hosts or services, or both.

To see how all your applications, services, containers, cloud services, hosts, and other entities work together, use New Relic One.

Using New Relic APM's transaction traces, slow query traces, and service maps, you can examine the specific query, database instance (host and port), and database name for the problem. New Relic APM's instance-level metrics can help you drill down to the specific instance or instances that are involved. This helps you quickly assess the impact and resolve the issue.

Access to this feature depends on your subscription level.

Compatibility and requirements

New Relic collects instance details for a variety of databases and database drivers. The ability to view specific instances and the types of database information in New Relic APM depends on your database driver and New Relic agent version:

To request instance-level information from datastores currently not listed for your New Relic agent, get support at

Use datastore instance details to monitor and troubleshoot your app

Use these examples as starting points to monitor and troubleshoot the performance of connections between your applications and associated datastore instances. The examples describe the New Relic capabilities that can help you determine whether the underlying cause behind app performance problems relates to your applications, a database instance configuration problem (such as a missing index), your organizations resources, or a combination.

Slow query trace details example

Your Apdex is falling, and you want to determine what is affecting your end users' experience with your app. On the New Relic APM Database page, you notice some slow queries, and you want to investigate further with your database vendor tools.

To do this, you need to know the database name and the instance where the slow query occurred, since the issue may be specific to the instance. For example, the problem may be a missing index. Use New Relic APM's slow query traces to review query performance, locate the database name and instance, and identify any poorly written or inefficient queries.

APM Databases slow query details: Database and instances information > (select an app) > Databases > (select a database operation) > (select a slow query) > Trace details: Here is an example of a slow query trace identifying a specific database and instance.
Transaction trace details example

Your app has a performance issue, and you have used the New Relic APM Transactions page to identify a suspect transaction. When you select a transaction trace for the slow transaction, you notice that the database time is the key contributor to the transaction performance.

From the selected transaction trace Details, you select the Database [database icon] icon to review the Database query information. This shows both the query details and the specific instance where the query was executed. From here you can use your database vendor tools to further diagnose the issue.

APM transaction trace: Database and instances information > (select an app) > Transactions > (select a trace) > Trace details: To view information about a specific database and instance that may be contributing to an app's performance problem, select the Database icon.
Service map details example

Your environment has performance issues, and you want to troubleshoot and assess the impact of a performance problem between a calling application and a specific database instance.

Use the APM Service maps page for a quick overview of your app's connections and dependencies, including databases and external services. Each datastore type has its own node on the map. From the selected service map details, you can:

  • Review the color-coded health status of the connections between your applications or external services and datastore instances. (New Relic uses a simple baseline technique to compare the performance over the past 15 minutes with the average over the past week.)
  • Select particular apps or instance types from their time series chart on the service map, then review their Response time or Requests per minute (throughput) for unexpected spikes in performance. (This can help you more easily identify outliers or "noisy neighbors" affecting resources or throughput time with other services.)
  • Select a datastore node to filter the chart by enabling or disabling individual instances (100 instances maximum). Your selections are saved when you save the map.
  • Identify outliers that may be causing unexpected impact on performance.

Once you identify the databases or instances with problems with New Relic's service maps, you can use New Relic’s transaction traces and slow query traces as well as your database vendor tools to further diagnose the issue.

screen-instance-details-in-service-maps.png > Service maps > (select a map) > (select a datastore node): By selecting an Instances node, you can drill down even further into performance problems. Within a selected node, you can enable or disable individual instances, and your selections are saved when you save the map.
Insights dashboards and widgets example

If you are using a New Relic APM agent that supports database instance details, you can use New Relic Insights to report on timeslice metrics, such as response time and throughput. You can also create and share custom dashboards and metric widgets that visualize performance problems or trends.

Alerting on custom metrics for instance performance example

To be notified about a performance issue between your app and a database instance before it adversely impacts your customers' experience, use New Relic Alerts. You can create alert policies that automatically notify appropriate personnel via PagerDuty, webhooks, etc. when problems escalate to the Critical thresholds you define.

As part of the alert policy configuration, create a condition with custom metrics for a specific instance, using this format:


For example:


For more help

If you need more help, check out these support and learning resources: