Aurora DSQL Now Shows You Exactly Which Query Is Making You Wait — CloudWatch Database Insights Support!

Hi, it's me, Shiichan! Today I've got a nice update from AWS What's New for anyone running Aurora DSQL.

AWS What's New aws.amazon.com

What was announced?

AWS What's New announced that Amazon Aurora DSQL now supports Amazon CloudWatch Database Insights. You can now see sampled wait states and normalized SQL text for every active session in a cluster, at both the per-statement and cluster level — useful for diagnosing performance issues and finding out which queries are eating the most resources.

The story so far

Aurora DSQL already had a built-in mechanism called DASH (DSQL Active Session History), which samples every active session in the cluster once a second and publishes 1-minute aggregated data as CloudWatch OTel metrics. DASH itself has been on by default since the moment you create a cluster, but making sense of that data — quickly seeing which SQL statement is causing waits — needed the same CloudWatch Database Insights view that RDS and (non-DSQL) Aurora users already know. That's exactly what's now available for Aurora DSQL too.

What changes

Open Database Insights and you'll see the database-load timeline by wait event in the upper pane, and the most active SQL statements for that period in the lower pane — the same familiar layout as RDS and Aurora.

Aurora DSQL scales elastically, so there's no Max vCPU line. Instead, you judge health by watching how the proportions of wait events shift over time. If the share of SequentialScanRead (a range read) suddenly jumps while Commit and OnCpu shrink, that's a sign an application or query-plan change is pushing more time into scanning.

Here's what you get:

• Metrics are captured at 1-minute intervals, on by default, at no extra cost
• Available in every AWS Region where Aurora DSQL runs
• The same DASH data can also be queried directly with CloudWatch PromQL
• The Aurora DSQL system diagnostics AI skill lets an AI agent run performance checks for you

Dive Deep

DASH samples every active session once a second. A session counts as active if it's consuming CPU, blocked on a wait event such as a storage or commit wait, or sitting in a transaction waiting for the application's next request. Each sample also records the first 256 characters of the SQL text that was running, so you get the "what" and the "what it was waiting on" together. Data is retained for 15 months, which is plenty for trend analysis, capacity planning, and chasing down intermittent issues.

DSQL has far fewer wait events than community PostgreSQL, which defines 273 of them in PostgreSQL 18. Because DSQL's query processor doesn't need to manage latches, data locks, or IPC, the list stays simple: OnCpu for CPU execution, ClientRead/ClientWrite for waiting on the application, Commit for commit acknowledgement, and SequentialScanRead/ScatteredBatchRead for storage reads.

If you'd rather query directly, CloudWatch Query Studio supports PromQL against the same data — for example, topk() queries for the top 5 queries by average active sessions, grouped by wait event.

There's also the databases-on-aws plugin, part of Agent Plugins for AWS. Ask an agent something like "Check the performance of my DSQL cluster in us-east-1 and write me a markdown report," and it compares against baselines like the last hour, the same hour yesterday, and the same hour last week — and automatically dives deeper into any query it flags as suspicious.

Wrap-up

• Amazon Aurora DSQL now supports Amazon CloudWatch Database Insights, showing wait states and SQL text at the per-statement and cluster level
• The underlying DASH data is now viewable through the same familiar screen RDS and Aurora users already know
• Captured every minute, on by default, free, and available in every Aurora DSQL Region
• The same data also works with direct PromQL queries and AI-agent-driven diagnostic reports
• A welcome, ready-to-use update for anyone running Aurora DSQL who wants to know at a glance which query is slowing things down!