Published on · Updated on
Updated the RDS monitoring guide for the Performance Insights console retirement and current Database Insights guidance.
If you used Amazon RDS Performance Insights to investigate a slow database, the monitoring experience has moved. AWS ended the Performance Insights console experience on July 31, 2026, and migrated its users to CloudWatch Database Insights. The Performance Insights API remains available. This guide explains how to use Database Insights to find what is driving database load, read the signals correctly, and choose a safe next step.
The most useful starting point is the database load chart. It breaks active sessions down by wait event, SQL statement, host, or user. Pair that view with CloudWatch resource metrics and application latency: Database Insights helps explain database activity, while those other signals help show whether the issue is CPU capacity, storage, a lock, a workload change, or something upstream.
Performance Insights' former RDS console dashboard is no longer the supported console experience. The old entry point redirects users to CloudWatch Database Insights. Existing RDS monitoring configuration and the Performance Insights API continue to use names such as EnablePerformanceInsights; their presence in an API request or infrastructure template does not mean the retired console is still in use. See the current CloudWatch Database Insights overview and the Performance Insights API reference for the current product and API details.
Database Insights is the monitoring experience for Amazon RDS and Amazon Aurora. It has Standard and Advanced modes with different capabilities. Support and configuration details depend on the database engine, Region, and instance class, so check the current AWS support page for the database you run before changing its settings.
Database Insights covers Amazon RDS for MariaDB, MySQL, PostgreSQL, Oracle, and SQL Server, as well as supported Amazon Aurora databases. Exact engine versions, Regions, and instance classes vary. Use the current Amazon RDS Database Insights support matrix and the separate Aurora matrix instead of relying on a copied list of versions or small-instance exclusions.
This article focuses on managed RDS and Aurora databases. Database Insights also has a separate setup for self-managed PostgreSQL on EC2; its modes and configuration are different.
For an RDS instance or Multi-AZ DB cluster, select Database Insights when creating or modifying the database. Standard mode provides the core DB load and top-contributor views. Advanced mode adds capabilities such as fleet views, detailed per-query statistics, selected execution-plan and lock analysis, and process-level operating-system views when their prerequisites are met. The supported features differ by engine and Region.
When a workflow or template still refers to Performance Insights, consult the current RDS instructions for the corresponding Database Insights setting. Do not assume that an older console walkthrough still matches today's labels or available choices.
Database Insights uses permissions across CloudWatch and RDS; features that display logs also depend on CloudWatch Logs access. Use the current AWS Database Insights permissions guidance to scope access for your account and enabled features. SQL text and workload dimensions can reveal sensitive application or customer details, so limit dashboard and query-text access to the people who need it.
Console choices can vary by database type. Follow the linked AWS procedure for the engine you are creating rather than treating these steps as a universal list of settings.
Choose the DB instance or cluster in the RDS console, select Modify, and review the Database Insights section. Pick the mode and retention appropriate for the workload, then apply the change using the options AWS presents. For a cluster, check whether monitoring settings are managed at the cluster level; do not try to change a setting independently on an instance when the cluster owns it.
For API or infrastructure-as-code changes, use the current engine-specific RDS documentation. AWS still uses Performance Insights API parameter names for some Database Insights settings, and Advanced mode requirements can differ between service-level summaries and engine-specific procedures.
The current CloudWatch Database Insights overview describes these retention options:
These statements describe retention for those metrics; they do not mean that the database, CloudWatch, logs, or every Advanced feature has no cost. Check the current CloudWatch pricing page for charges tied to your configuration and Region.
AWS documentation is not fully aligned: the CloudWatch mode overview lists flexible 1–24 month retention for Advanced mode, while the current RDS Advanced-mode setup procedure still specifies a 15-month minimum (465 days) for enabling it. Do not copy a fixed retention value from an older CLI example. Check the current console or engine-specific procedure for the exact database you are changing, and confirm the applicable cost before applying the change.
Database Insights offers a fleet view for finding databases that need attention and an instance view for investigating one database. The instance view brings the database load chart and related metrics together. Select a DB instance, choose the time range that matches the reported symptom, then compare the same interval with application latency, request volume, database events, and CloudWatch metrics.
Database load, or DBLoad, is measured as average active sessions (AAS). An active session has submitted work and is either running on the CPU or waiting for a resource. AAS is therefore a measure of concurrent database activity, not a CPU percentage and not a count of every open connection.
The chart can divide load by dimensions such as waits and SQL. A maximum-vCPU line gives a reference for the instance's CPU capacity. Read that line together with the wait breakdown: load above the line with CPU as the main load component can indicate CPU pressure, while load dominated by storage or lock waits points to a different investigation.
The Top SQL view ranks statement patterns by their contribution to DB load and shows related statistics. It helps distinguish a widely used query pattern from an isolated slow request. A high ranking identifies where to investigate; it does not prove that the SQL itself is defective. Compare the statement's load, call rate, and timing with the period when the application slowed down.
AAS is the average number of sessions actively doing database work during an interval. If AAS rises with application traffic, the database may simply be serving more work. If latency rises while traffic is steady, inspect which waits and SQL statements make up the increase. Idle connections do not count as active sessions just because they are open.
Compare DB load with the maximum-vCPU reference and the database's CloudWatch CPUUtilization metric. AAS can be high because sessions are waiting; it does not by itself establish CPU saturation. The AWS database load guide explains AAS, active sessions, waits, and dimensions.
Start with the largest DB load contributors, then check the matching resource signals and database context:
Use the evidence to form a hypothesis, then validate it against the application symptom and a comparable workload period before changing instance size, indexing, query shape, or connection behavior.
Each dimension answers a different question. The wait breakdown separates CPU activity from sessions waiting on I/O, locks, or other engine resources. SQL points to the statement patterns contributing to load. Host and user can help identify where or under which database identity the work runs. Use these dimensions together: for example, a storage wait concentrated in one SQL pattern is more actionable than a database-wide I/O counter alone.
Availability of dimensions and detail differs by engine. Keep in mind that a host or database user is not necessarily the same thing as an application service, and the dashboard cannot infer application ownership when the database does not expose that association.
Database Insights' DB load and wait events describe database sessions. Amazon CloudWatch's RDS metrics describe other signals, such as CPU utilization, freeable memory, connections, storage throughput, and latency. Enhanced Monitoring exposes operating-system-level metrics; Advanced Database Insights can show detailed processes when RDS Enhanced Monitoring is enabled. These signals answer related but different questions, so do not label an OS metric as a database wait or treat every counter as query attribution.
For an apparent CPU issue, compare CPU utilization with DB load and the CPU portion of DB load. For an I/O issue, examine the relevant read/write latency and throughput metrics along with I/O waits. For connection pressure, look at connection counts and the sessions consuming load. The metric set and names vary by engine; compare a useful baseline and the affected interval instead of relying on a single universal threshold.
Top SQL commonly groups statements with the same parameterized shape into a digest. This reduces noise from queries that differ only in literal values. Use the digest to locate a costly pattern, then inspect its call volume and available query-level statistics. The exact statistics depend on the database engine and mode.
High total load and high latency per call are different signals. A fast query called extremely often can dominate load; a slow query called rarely may have little effect on the overall database.
Execution plans show how the database engine intends to access and combine data. Database Insights plan capture and guided analysis require Advanced mode and are available only for selected engines. Check the current feature matrix for your engine before expecting plans in the console. Review a plan with the query's statistics and schema; a scan or join is not automatically a defect without workload context.
Database Insights is a CloudWatch experience, and supported RDS metrics are available in CloudWatch for graphs and alarms. Advanced mode can also import Performance Insights counter metrics into CloudWatch automatically. You do not need to build a Lambda function that copies every metric through the API just to use the built-in database views. The Performance Insights API remains available for custom integrations or workflows that need it.
Choose a metric or alarm condition that corresponds to a user-visible problem or a confirmed capacity risk. Combine a DB load signal with a resource or application metric when that reduces false alarms, and set periods and evaluation rules from observed workload behavior. Avoid paging on a short, harmless spike. See the related guide to CloudWatch alarm thresholds and conditions for practical alarm design.
CloudWatch metrics and logs add resource and event context; application tracing or service telemetry can show which upstream request generated work. Use these together with database waits and SQL to distinguish a database bottleneck from a traffic surge or application behavior. Slow SQL visibility in Database Insights requires database log export to CloudWatch Logs and the engine-specific configuration described in the AWS guide.
If SQL contributes most of the load, inspect query frequency, plans, indexes, and the application call pattern. If waits are caused by storage, locks, or a constrained instance, check those resources and their limits. Make one well-scoped change at a time where practical and measure the result. For broader RDS tuning strategies, see the RDS performance tuning guide.
Database Insights samples database activity and presents selected metrics. It does not, on its own, prove that a specific SQL statement caused application latency, that a CPU spike requires a larger class, or that every query pattern is unhealthy. Confirm the timing and impact with application metrics, resource headroom, database logs, and a repeatable test when the proposed change carries operational risk.
| Signal or tool | What it helps answer | What it does not establish alone |
|---|---|---|
| Database Insights DB load and waits | How many sessions are active, what they are waiting for, and which SQL patterns contribute most to load. | Whether the application symptom came only from the database, or which resource change will fix it. |
| Amazon CloudWatch RDS metrics | How CPU, memory, connections, storage performance, and other supported resource measures changed over time. | Which statement or transaction produced a metric change. |
| RDS Enhanced Monitoring and database logs | Operating-system process detail and engine-specific diagnostic records when enabled and configured. | A complete workload explanation without correlating the data to DB load and application behavior. |
Database Insights is useful when you need a managed view of RDS/Aurora load, waits, and leading SQL contributors. Its value depends on the engine, Region, mode, retention, and configured log or monitoring prerequisites. CloudWatch resource metrics and Enhanced Monitoring add different context; database-native tools and application tracing may still be needed for details those views do not collect.
Use a query-level finding to investigate SQL and its execution plan; use sustained CPU load plus high CPU utilization to evaluate compute capacity; use I/O waits with storage metrics to investigate storage or access patterns; and use lock waits to investigate transaction behavior. If the evidence points to persistent capacity mismatch, the RDS rightsizing guide covers how to compare resource demand before changing an instance class.
For the current feature matrix and setup instructions, start with the CloudWatch Database Insights documentation and follow its engine-specific RDS or Aurora links.