Amazon Aurora DSQL now provides time-based observability through Amazon CloudWatch Database Insights, linking session wait time directly to DPU-based cost. The post explains DSQL Active Session History (DASH), which samples active sessions every second and aggregates them into 1-minute CloudWatch OTel metrics, enabled by default at no extra cost with 15 months of retention. It details the small set of DSQL wait events (compared to PostgreSQL's 273), how to query DASH data directly with PromQL in CloudWatch Query Studio, how to judge application health by comparing wait-event proportions rather than absolute counts (since DSQL has no fixed vCPU ceiling), and introduces a DSQL system diagnostics AI skill built on the databases-on-aws Agent Plugin that uses the CloudWatch MCP server to generate performance reports and flag problematic queries.
Table of contents
Why time-based observability?An introduction to DASHCloudWatch Database InsightsWait eventsSQL statementsDirect query with PromQLApplication healthDSQL system diagnostics AI skillConclusionAbout the authorQuestions this post answers
How does Amazon Aurora DSQL determine if a session is active for observability purposes?
A DSQL session is considered active if it is actively consuming CPU, blocked on a wait event such as storage or commit waits, or sitting idle within a transaction waiting for the next request from the application. DSQL Active Session History (DASH) samples every active session once per second and publishes 1-minute aggregated data points as CloudWatch OTel metrics, enabled by default on every cluster at no extra cost. Track how database internals like session activity models evolve by following Aurora DSQL coverage on daily.dev.
How many wait events does Amazon Aurora DSQL have compared to PostgreSQL?
Aurora DSQL currently defines only 11 wait events, far fewer than the 273 defined in PostgreSQL 18. This is because the DSQL query processor does not need to manage latches (LWLock), data locks, or IPC, which account for most wait events in community PostgreSQL. Examples include OnCpu, ClientRead, Commit, ScatteredBatchRead, and UniqueConstraintCheck. Developers comparing distributed SQL internals to PostgreSQL can keep up with these deep dives on daily.dev.
How do you judge whether an Amazon Aurora DSQL cluster is healthy since it has no fixed vCPU limit?
Health is judged by comparing the relative proportions of wait events over time rather than absolute waiter counts, since DSQL scales elastically and has no Max vCPU ceiling. For example, if SequentialScanRead, Commit, and OnCpu normally sit at roughly 40/10/50 waiters, a shift to 90/3/7 signals a problem such as an application or SQL plan change, even if the total waiter count stays similar or grows. Anyone building alerting for elastically scaled databases can follow practical health-check patterns like this on daily.dev.