Database Monitoring Tools: SolarWinds vs New Relic vs Datadog

updated on Nov 30, 2025

We installed three database monitoring platforms on a clean system running MySQL to see how they handle database monitoring from scratch.

We examined: ease of setup, onboarding experience, agent resource consumption, accuracy in metric measurement, and effectiveness of their alerting systems’ notifications when issues arise under real-world database workloads.

What we tested

We deployed agents from SolarWinds, New Relic, and Datadog on the same server to monitor a MySQL instance. Each tool went through its complete installation process, and we tracked:

How the onboarding flow guides you through setup
What the installation process asks of you
Agent resource consumption (memory and CPU usage)
Metric accuracy during database load
Alert configuration and notification speed
Dashboard usability and information architecture

Test Environment

All tests ran on an Amazon EC2 m6i.xlarge instance with the following specifications:

Processor: Intel Xeon 8375C (Ice Lake)
vCPUs: 4 cores
Memory: 16 GB
Storage: 128 GB with 3,000 IOPS and 125 MB/s throughput

We conducted three types of tests:

Zero load monitoring – Agents running with idle MySQL (6 minutes)
Heavy load monitoring – Agents running during a 26 GB database import (approximately 2.5 hours)
Alert functionality – Alert configuration, channel availability, and alert quality
Alert speed testing – Notification delivery speed across email and Slack
Dashboard evaluation– Assessment of UI functionality and information architecture

Methodology

We tested each platform using identical conditions to ensure fair comparison.

Installation: Started with fresh agent installations on the same server. Followed each platform’s default onboarding flow without advanced configuration. Documented every step, including screenshots.

Resource monitoring: Ran custom scripts to collect agent CPU, memory, disk I/O, and network usage every 2 seconds. Tested under two scenarios: idle MySQL and during a 26 GB database import.

Metric accuracy: Ran database import to stress the system and evaluated how accurately each platform measured CPU usage, memory consumption, and network traffic against actual system values.

Alerting: Configured identical alerts (memory >50% for 1 minute) across all platforms. Used stress-ng to trigger the alert by pushing memory to 70%. Measured notification delivery time and tested multiple channels.

Dashboard evaluation: Assessed default, out-of-the-box dashboards immediately after setup. No custom configuration, we evaluated what each platform provides automatically.

All tests used default settings. These platforms offer extensive customization options, but we focused on the first-day experience: what you get when you install the agent and start collecting data.

Installation & Onboarding Experience

1. SolarWinds

SolarWinds opens with a question: What do you want to monitor?

When you select database performance, supported databases are shown upfront.

After selecting MySQL, the platform checks whether any agents are already running.

One feature stood out: if you have a Kubernetes agent installed, SolarWinds automatically detects databases running in your cluster. You can select them without manual configuration.

SolarWinds offers multiple installation methods:

Automatic detection (detects OS and version automatically)
Manual installation by specifying OS
Automation scripts (Ansible, Chef, Puppet, SaltStack)
Docker image
Kubernetes agent deployment

We selected the recommended option: script-based installation.

The installation script is straightforward. SolarWinds first asks you to create an API key, then lets you specify a hostname for your instance.

After creating the API key, you specify a hostname for the instance. We named ours “AIMULTIPLE-MYSQL” and enabled host monitoring to track server metrics alongside database stats.

Copy the script, run it on the server, and the agent installs. The script includes the API key automatically, so no additional configuration is needed.

We expected to see a ‘successfully installed’ confirmation, but nothing appears. The command just finishes, and you’re left assuming it worked.

After installation, SolarWinds offers to enable log monitoring for all server logs. We skipped this.

Then it presents default alert templates. These are host-level alerts (CPU, memory, disk) since we enabled host monitoring earlier. No MySQL-specific alerts appear at this stage, even though we’re setting up database monitoring.

The confusing part: SolarWinds installed its base agent, not the MySQL monitoring agent. You have to go back and add database monitoring separately. The UI doesn’t make this clear during initial setup.

Now SolarWinds asks for MySQL credentials. The interface could be clearer, as it doesn’t explain upfront what permissions the monitoring user needs.

But here’s the interesting part: when you enter a username and password, SolarWinds generates a complete SQL script to create that user with all necessary permissions.

The problem: the previous screen doesn’t mention this script exists. In our test, we created a monitoring user manually, only to discover later that SolarWinds generates the creation script automatically.

The generated SQL script creates the user, grants performance schema access, and configures all required permissions. Copy these commands, run them in MySQL, then apply any recommended MySQL configuration changes.

One inconsistency: the default username field displays “user on [system hostname]” rather than the hostname specified during agent installation. In our case, we named the instance “AIMULTIPLE-MYSQL” during setup, but the interface showed the server’s actual hostname instead.

After running the SQL commands and updating the MySQL config, click “Observe database.”

The dashboard appears, empty and ready to collect data.

Discover SolarWinds Database Observability with deep MySQL monitoring and query profiling. Explore SolarWinds.

Visit Website

2. New Relic

New Relic takes a different approach. Instead of asking what to monitor, it starts with agent installation.

After logging in, the onboarding screen prompts to install the agent first. Select Linux as the operating system.

Since no API key exists yet, New Relic asks to create one.

The platform generates the key automatically and immediately provides the installation script.

The interface includes a helpful toggle: “automatically answer yes to all prompts.” Enable this for smoother installation.

Running the script on the server reveals something interesting: New Relic’s agent scans the system during installation and automatically detects MySQL. It attempts to install the MySQL integration on its own, without user intervention. But the installation fails.

Selecting “automated on-host” installation, New Relic asks to either create a new API key or use an existing one. Choosing to use the existing key doesn’t offer a dropdown; it requires pasting the key manually. This makes creating a new key simpler, so that’s what we did.

The slow query monitoring toggle is a nice touch.

But here’s an odd request: New Relic asks to specify the database type: self-hosted, RDS, or Aurora. The agent is already installed on the server and detected MySQL earlier. It should know the deployment type.

New Relic provides another installation script.

During installation, the CLI prompts for MySQL access credentials. Unlike SolarWinds, which provides a SQL script in the UI, New Relic asks for the root password directly in the terminal.

The initial prompt suggests using root, which most users won’t provide even in a test environment.

The confusion: it’s asking for root credentials to automatically create a monitoring user, not to use root for monitoring. The interface should present two clear options: “I’ll create the user myself” or “Create the user automatically (requires root password).”

Checking the database confirms a “newrelic” user exists. But New Relic doesn’t show what permissions this user has. Transparency here would help display the granted permissions (e.g., “Created user ‘newrelic’ with SELECT, PROCESS, and REPLICATION CLIENT permissions”) when requesting root access, thereby setting clearer expectations.

After installation completed, we expected to see a MySQL-specific dashboard. Instead, the interface showed a generic dashboard with options to create custom visualizations. No pre-built MySQL dashboard appeared automatically.

The setup process didn’t make it clear whether:

A MySQL dashboard would appear later after data collection
We needed to build one manually
We missed a configuration step

We waited to see if a dashboard would populate with data over time.

Installation Summary

Time to complete: ~8 minutes
Complexity: Low (automated user creation)
Strengths: Fastest setup, automatic user creation, single-phase installation
Weaknesses: Unclear root password request, no pre-built MySQL dashboard, manual setup path not obvious

Datadog

Datadog’s approach is the most hands-on of the three platforms.

After logging in, the interface prompts to install the base agent first. Multiple deployment methods are available. We selected Linux for installation.

Datadog prompts for an API key. Creating one is straightforward; the process advances automatically.

Copy the installation script and run it on the server.

The agent installs quickly. But unlike SolarWinds or New Relic, nothing happens next, no MySQL detection, no prompts to set up database monitoring. We had to navigate to the Marketplace manually and search for MySQL.

After selecting the MySQL integration, a pop-up appears with installation instructions.

Datadog provides a checklist:

Create a monitoring user in MySQL
Grant permissions
Write a YAML configuration file
Place it in `/etc/datadog-agent/conf.d/mysql.d/conf.yaml`

The configuration file path isn’t prominently shown in the UI. You need to know where Datadog stores integration configs, or scroll through the documentation to find it.

This approach is more advanced and technical compared to SolarWinds’ UI-guided setup or New Relic’s automatic user creation. You’re editing files manually and restarting services from the command line. We created the MySQL user with the required permissions, wrote the YAML configuration file, placed it in the correct directory, and restarted the Datadog agent to complete setup.

After the restart, the Datadog dashboard appeared with basic MySQL metrics ready to collect data.

Installation Summary

Time to complete: ~12 minutes
Complexity: High (manual YAML configuration, no guided setup)
Strengths: Full control over configuration, works well if you know Datadog already
Weaknesses: No automatic detection, requires manual file editing, not beginner-friendly, file path not obvious in UI

Note: This covers the basic installation path. Datadog, SolarWinds, and New Relic offer many additional configuration options for advanced monitoring. These tests focused on the default onboarding experience.

Agent Resource Consumption

We tested agent resource usage under two scenarios: zero database load (idle monitoring) and heavy load (during a 26 GB database import). Both tests ran for approximately 6-7 minutes with all three agents collecting data simultaneously.

CPU Consumption

CPU consumption remained minimal across all agents. Under heavy database load, average usage stayed well under 1% for all three platforms.
Datadog showed the highest spike at 3.20% during heavy load, but these bursts were brief and infrequent. All three agents spent most of their time idle or under 0.5% CPU utilization.

Memory Usage

New Relic consumed significantly less memory, roughly 3-5x less than the other two platforms. Memory usage remained stable across both idle and heavy-load scenarios for all three agents.

Disk I/O

Zero Load

Heavy Load

Disk I/O patterns showed distinct characteristics for each agent:

Datadog read the most from disk but wrote the least. This suggests more frequent disk access for data retrieval with minimal local buffering.
SolarWinds wrote significantly more data locally than the other two about 2-3x more. This indicates aggressive local buffering or more detailed logging.
New Relic balanced reads and writes, performing the fewest disk reads while maintaining moderate write activity.

Interestingly, disk I/O actually decreased slightly under heavy database load for all three agents. The agents’ disk activity didn’t scale with the database workload; they maintained consistent patterns regardless of MySQL’s workload.

Metric Accuracy

We ran a 26 GB database import to stress the system and evaluate how accurately each platform measured resource consumption.

CPU Measurement

All three platforms tracked CPU usage during the import with similar accuracy. SolarWinds and Datadog provided 1-minute granularity, while New Relic sampled every 2 minutes. The measurements aligned across platforms no significant discrepancies.

SolarWinds CPU graph – showing ~45-60% usage during import

New Relic CPU graph – showing a similar pattern

Datadog CPU graph – showing a stacked area chart of CPU states

Memory Measurement

This revealed a critical issue with New Relic.

During the import, the server consumed close to 100% of available RAM. Here’s what each platform reported:

SolarWinds: Accurately showed ~100% memory usage

New Relic: Reported only ~10% memory usage

Datadog memory graph – showing RAM total vs RAM used at ~16GB

New Relic completely missed the memory spike. This isn’t a minor measurement error; it’s an order of magnitude off. If you’re relying on memory alerts or capacity planning, this kind of inaccuracy undermines the entire monitoring setup.

Network Measurement

New Relic and Datadog captured network traffic accurately during the import, SolarWinds underreported network usage, missing some of the activity.

SolarWinds network graph – showing network throughput with some data gaps

New Relic network graph – showing complete network receive/transmit data

Datadog network graph – showing accurate network traffic capture

Measurement granularity remained consistent with CPU: SolarWinds and Datadog sampled every minute, New Relic every 2 minutes.

Alerting Performance

We configured the same alert across all three platforms: send a notification if memory usage exceeds 50% for 1 minute. Then we triggered the alert manually using the stress-ng tool to push memory utilization to 70%.

SolarWinds alert configuration – showing memory threshold set to >50% for 1 minute

New Relic alert configuration – showing guided mode with threshold settings and time series preview

Datadog alert configuration – showing metric monitor setup with evaluation details

All alerts were set to “Critical” priority. We tested email and Slack notifications.

Alert Configuration

New Relic offers the most granular timing controls. While SolarWinds and Datadog require minimum 1-minute duration thresholds, New Relic allows you to set alerts for conditions lasting as little as 10 seconds. This flexibility helps catch brief spikes that might resolve before hitting the 1-minute mark on other platforms.

SolarWinds and Datadog both require 1-minute minimum durations for threshold alerts.

Notification Channels

New Relic and SolarWinds both offer notification options. Datadog only accepted email notifications in our default setup it may require additional configuration for other channels.

New Relic notification options – showing an extensive list including ServiceNow, Webhooks, Jira, Slack, Microsoft Teams, Email, PagerDuty

SolarWinds notification options – showing service dropdown with AmazonSNS, Email, Microsoft Teams, New Relic, OpsGenie, PagerDuty, ServiceNow

Notification Speed

We started the memory stress test. Memory hit 70% almost instantly and stayed above 50% for over 1 minute. Here’s when alerts arrived:

Email notifications:

New Relic – First to arrive

Datadog – Second

SolarWinds – Last

Slack notifications:

We tested Slack integration for New Relic and SolarWinds (Datadog didn’t support Slack in our configuration).

New Relic – Delivered first, and included interactive buttons directly in the Slack message for acknowledging or investigating alerts
SolarWinds – Delivered second, but as plain text notifications

New Relic’s Slack integration stood out. The interactive message format lets you take action without leaving Slack.

Resolution Notifications

When memory usage returned to normal:

New Relic sent a resolution notification
Datadog sent a resolution notification
SolarWinds did not send a resolution notification

Email Content Quality

Datadog’s alert emails included clear context: what triggered the alert, current values, and a direct link to relevant dashboards. Professional and informative.

New Relic’s alert emails followed a similar format with good detail and clear calls to action.

SolarWinds’ alert emails were sparse, with minimal detail, poor formatting, and less actionable information. The emails worked, but they felt less polished than those on the other two platforms.

Slack Integration Setup

New Relic: Click “add Slack,” authenticate instantly, and select channels. Straightforward.

SolarWinds: Click “add Slack,” authenticate, and select channels. Equally straightforward.

Both took under a minute to configure.

Dashboard & UI Comparison

We evaluated the default MySQL dashboards each platform provides out of the box. These aren’t customized views, this is what you see immediately after installing the agent and collecting data.

Dashboard Overview

SolarWinds opens directly to a MySQL-specific dashboard from the left menu. The landing page shows:

Average response time
Throughput
Query errors
Active connections

This is what a database administrator or CTO wants to see first. The metrics are high-level, actionable, and immediately helpful in assessing database health.

SolarWinds MySQL dashboard overview – showing Quality of Service metrics with response time, throughput, and error graphs

New Relic presents a more data-dense dashboard with multiple graphs showing metrics over time. There’s a lot of information connections per second, query duration, throughput, but it’s organized as time-series charts rather than current-state summaries. You get detailed trends but fewer at-a-glance numbers.

New Relic MySQL dashboard – showing database connections, operations, queries, and throughput graphs

Datadog shows the most minimal default dashboard. It displays some basic metrics but lacks the depth of SolarWinds or the trend detail of New Relic. One oddity: “failed connects” appears prominently at the top of a security-focused metric that’s rarely the first thing you need when checking database performance.

Datadog MySQL dashboard – showing basic activity monitor with performance and throughput sections

Detailed Analysis Features

SolarWinds includes several tabs beyond the overview:

Inventory – Shows the most frequently used query patterns, wait times (what’s causing queries to slow down), and detailed filtering options. You can see which queries consume the most resources and where bottlenecks occur.

Profilers – Displays query patterns ranked by total execution time and CPU consumption. This is critical for optimization: you can identify which query types are costing you the most and prioritize fixes accordingly. Sorting and filtering options make it easy to find problem queries.

Health – Assesses overall database health and flags issues. During our test with normal operation, it showed green.

Queries – Lists all queries, grouped by pattern, with extensive filtering. Click any query to see how many times it ran, average execution time, and other statistics.

Resources – Shows host-level metrics (CPU, memory, disk) alongside MySQL metrics. This context helps distinguish between database issues and underlying infrastructure problems.

Advisors – Provides recommendations for performance, security, and configuration improvements. This feature doesn’t exist in New Relic or Datadog’s default dashboards. SolarWinds actively suggests optimizations rather than just displaying data.

New Relic organizes information differently. The dashboard focuses on time-series visualizations, lots of graphs showing trends. You can drill into specific time periods and see detailed breakdowns, but there’s less emphasis on tabular data or current-state summaries. The interface feels more suited to exploring historical patterns than getting immediate answers about the current state.

Datadog keeps the dashboard simpler. It shows basic MySQL metrics and, helpfully, includes host resource consumption on the same page. However, it lacks the query-level analysis and optimization features that SolarWinds provides.

Host Monitoring Dashboards

We also checked each platform’s general host monitoring dashboard (not MySQL-specific).

SolarWinds delivers exactly what a database administrator needs: a functional, organized interface focused on actionable MySQL insights rather than visual polish.

New Relic presents a clean, uncluttered view. Key metrics are easy to spot, and the interface doesn’t overwhelm you with information. It’s fancy and modern but still functional.

Datadog shows detailed information but with a busier layout. More advanced metrics are available, but there are fewer at-a-glance summary numbers. The visual presentation is straightforward but less polished than Solarwinds.

Query-Level Detail

This is where SolarWinds separates itself from the competition.

When you select a specific query pattern in SolarWinds, you get advanced statistics:

Total executions
Average execution time
CPU consumption breakdown
Lock wait times
Rows examined vs. rows returned and more

New Relic and Datadog show query metrics, but the level of detail and ease of navigation don’t match SolarWinds’ dedicated query profiling tools.

Customization Note

All three platforms let you build custom dashboards. You can drag and drop widgets, add your own queries, and create precisely the views you need. Our evaluation focused on default, out-of-the-box dashboards because that’s what you’ll use during the first hours or days with a new monitoring platform.

SolarWinds provides query-level analysis and optimization features that don’t exist in New Relic or Datadog’s default dashboards or even in their custom dashboard builders. The Profilers tab, Advisors feature, and detailed query execution breakdowns are unique to SolarWinds’ MySQL monitoring approach.

Next to Read

DatabasesNov 2