RDS Performance Insights: Find Slow Queries Fast (2026)

RDS Performance Insights is a monitoring tool that helps you identify performance bottlenecks in your Amazon RDS database instances.

Here’s a look at how it works and how you can leverage it to find slow queries.

The Problem: Database Performance Degradation

Imagine your application’s response times are creeping up. Users are complaining, and you’re not sure why. Your database is the usual suspect. But with potentially thousands of queries running every minute, pinpointing the exact ones causing the slowdown is like finding a needle in a haystack. This is where RDS Performance Insights shines.

Performance Insights in Action

Let’s say you’re using a PostgreSQL RDS instance. You’ve noticed increased latency.

Enabling Performance Insights: First, you need to ensure Performance Insights is enabled for your RDS instance. You can do this via the AWS Management Console. Navigate to your RDS instance, select the "Configuration" tab, and under "Performance Insights," ensure "Enabled" is set to "Yes." You’ll also want to set a retention period, typically 7 days is sufficient for most troubleshooting.
Accessing the Dashboard: Once enabled, you’ll find a "Performance Insights" tab on your RDS instance’s dashboard. Clicking this brings you to a visual representation of your database’s performance over time.

The primary view is a "Load Chart." This chart displays the database load, broken down by "Waits." Waits represent time spent by database processes that are not actively computing. High wait times are your primary indicator of a problem. Performance Insights categorizes these waits into types like CPU, IO, Lock, Network, etc.

For example, you might see a spike in CPU waits. This suggests that your database server is spending a lot of time waiting for CPU resources, likely because a query or queries are consuming too much processing power. Conversely, a spike in IO waits points to disk I/O bottlenecks, meaning queries are waiting for data to be read from or written to disk.
Drilling Down to Queries: Below the Load Chart, you’ll find a "Top Queries" section. This is where you can directly identify the problematic SQL statements. Performance Insights aggregates query activity by SQL text, showing you metrics like average active sessions (AAS) for each query. AAS is a crucial metric: it represents the average number of sessions that were actively working on a particular query during a given time period. A high AAS for a specific query during a period of high database load is a strong indicator that this query is a significant contributor to the performance issue.

Let’s say you see a query like SELECT * FROM large_table WHERE some_column = 'some_value' with a very high AAS. This is your prime suspect.
Analyzing Query Details: Clicking on a specific query in the "Top Queries" list reveals even more detailed information. You can see the breakdown of waits for that specific query. This is incredibly powerful. If the SELECT statement above is showing high IO waits, you know it’s likely performing inefficient disk reads. If it’s showing high CPU waits, it might be doing complex calculations or inefficient full table scans.

The "SQL Text" view will show you the exact SQL statement, and importantly, "Normalized SQL" which groups similar queries (e.g., SELECT ... WHERE id = 1 and SELECT ... WHERE id = 2 would be normalized to SELECT ... WHERE id = ?). This helps you see the overall impact of a query pattern, not just individual executions.

The Mental Model: Database Load as a Resource Competition

Think of your database server as a busy restaurant. The "Database Load" is the total number of customers (database sessions) who are either eating (computing) or waiting for their food/bill (waiting). "Waits" are the different reasons customers are waiting: waiting for a table (CPU), waiting for their order to be cooked (IO), waiting for the waiter (Lock), etc.

Performance Insights helps you see the total number of waiting customers and, crucially, why they are waiting and which tables (queries) are causing the most prolonged waits. The "Top Queries" section is like the maître d’ telling you which specific groups (queries) are occupying tables for an unusually long time, leading to a backlog of other waiting customers.

The "Waits" breakdown is like the maître d’ reporting that a particular table is waiting because their food is taking too long to prepare (IO), or because the waiter is overwhelmed (CPU).

The Lever: Query Optimization and Indexing

Once you’ve identified a slow query, the next step is optimization. For our example SELECT * FROM large_table WHERE some_column = 'some_value', if it’s showing high IO waits, it’s likely performing a full table scan. The solution is often to add an index on some_column.

Diagnosis: Use EXPLAIN in your database client:

EXPLAIN SELECT * FROM large_table WHERE some_column = 'some_value';

Look for "Seq Scan" (Sequential Scan) on large_table.

Fix:

CREATE INDEX idx_large_table_some_column ON large_table (some_column);

Why it works: An index is like the index at the back of a book. Instead of reading every page to find a specific word, you can quickly jump to the relevant pages. This drastically reduces the amount of data the database needs to read from disk, thus lowering IO waits.

If the query shows high CPU waits, it might be performing complex joins or aggregations. Analyzing the EXPLAIN plan will reveal the most expensive operations, and you can then refactor the query or add indexes to support those operations.

The "Normalized SQL" feature is key to understanding the impact of parameterized queries. If you see a normalized query with high load, it means that all executions of that query pattern, regardless of the specific parameters, are collectively causing the bottleneck. This often points to a need for a general index or a fundamental query rewrite.

The Next Step

After optimizing your slow queries, you’ll want to monitor the impact. The next logical step is to investigate database connection management and potential connection pool exhaustion, which can manifest as high CPU or Lock waits if not configured correctly.