Eight days. That is what remains before AWS retires Performance Insights, the query-level monitoring tool that RDS and Aurora teams have relied on since 2017.
The deprecation date is June 30, 2026. If you take no action before then, AWS will automatically migrate your instances to the Standard mode of CloudWatch Database Insights and you will lose capabilities your team may not have realized it depended on, including execution plan history and on-demand incident analysis.
This guide covers what is changing, what you lose by defaulting to Standard mode versus what Advanced mode restores, how to evaluate the migration for your fleet, and what this transition means for teams moving toward autonomous database reliability.
What AWS Announced
AWS is retiring Performance Insights and replacing it with CloudWatch Database Insights, available in two tiers:
Standard mode: the default landing zone for teams that take no action before June 30. Provides 7 days of data retention at no additional charge. What you lose compared to the Performance Insights paid tier: execution plan history, on-demand analysis in the Amazon RDS console, retention beyond 7 days, and some counters and dimensions that teams have built dashboards and alerting around.
Advanced mode: extends retention to 15 months, restores execution plan history and on-demand analysis, and provides enhanced wait event breakdowns. Pricing scales with vCPU count. pganalyze's breakdown puts the cost at $100+/month per large instance, a meaningful consideration for large fleets.
What You Lose in Standard Mode
For teams currently on the free tier of Performance Insights (7-day retention, basic wait event data), Standard mode migration is functionally a no-op. Same capabilities, new service name.
For teams on the paid tier, the losses are material:
Execution plan history is the capability your DBA or on-call engineer reaches for during regression diagnosis: "what query plan was this using three weeks ago, before the performance drop?" Standard mode does not include it. Without plan history, retroactive analysis means reconstructing context from logs rather than examining captured plan data.
On-demand analysis allows targeted examination of specific time windows, critical during active incidents. This is the Performance Insights feature that turns a broad alert ("something is wrong") into a specific diagnosis ("this query's plan changed and is now doing a full sequential scan on the orders table"). Not available in Standard mode.
Retention beyond 7 days matters for capacity planning, seasonal trend analysis, and correlating database performance with application deployments. Seven days is enough to investigate a recent incident; it is not enough to identify a slow-growing degradation or compare performance across a quarter.
Existing automation, dashboards, and alerting will break if not updated. The CloudWatch Database Insights metrics namespace and API surface are not identical to Performance Insights. Any Terraform, CloudFormation, or CDK that references Performance Insights APIs will need updating before the cutover.
The Migration Decision Framework
AWS recommends that teams on the Performance Insights paid tier upgrade to Advanced mode before June 30. For most teams that rely on the full feature set, that is the right default, but stress-test it before committing your fleet.
Step 1: Inventory before June 28. Identify every RDS and Aurora instance using Performance Insights. Separate free-tier instances (Standard mode migration is fine) from paid-tier instances (active decision required). Pull actual usage data: what retention window do your engineers actually use? What analysis features do they reach for during incidents?
Step 2: Cost-model your fleet. Advanced mode pricing scales with vCPU count. For a large fleet (dozens of large RDS instances), monthly Advanced mode cost can exceed what you were paying for Performance Insights. Do the arithmetic before enabling fleet-wide.
Step 3: Evaluate third-party alternatives. pganalyze, Datadog, New Relic, and purpose-built database observability platforms all offer query-level monitoring independent of the Performance Insights lifecycle. If you are already running a third-party monitoring agent alongside Performance Insights, this deprecation is a natural moment to consolidate. It also surfaces a strategic question: do you want database observability tied to the AWS console and CloudWatch, or a portable multi-cloud monitoring stack?
Step 4: Check region coverage. Database Insights availability and feature parity is not uniform across all AWS regions. Verify Advanced mode is available in every region where you run RDS before assuming the upgrade path is consistent.
Step 5: Update IaC and alerting before June 30. Update any Terraform, CloudFormation, or CDK that references Performance Insights resource names, APIs, or metric namespaces. Update alerting thresholds if metric names or dimensions have changed. Run a synthetic incident drill to confirm on-demand analysis is accessible in the new console experience before you need it in production.
Common Migration Mistakes
Waiting until June 30. The cutover is hard. Teams that start migration on the deadline day will triage dashboard breaks, alerting failures, and missing data simultaneously. Start the inventory today.
Assuming Standard mode is equivalent. If your incident response process relies on execution plan history or on-demand analysis (and most mature teams' processes do), Standard mode will break workflows you have not documented as dependencies. Audit before the cutover, not after.
Treating this as a one-time migration. CloudWatch Database Insights is a moving target. Build your monitoring stack to be independent enough to absorb future AWS product changes rather than tightly coupled to a specific API surface.
The Broader Context: AWS Is Converging Toward AI-Driven Database Observability
The Performance Insights deprecation is a product lifecycle event, but it arrives at an inflection point for the database monitoring category.
AWS is not deprecating performance monitoring. It is consolidating database telemetry under CloudWatch to create a unified observability surface that can feed AI-driven analysis workflows. CloudWatch Database Insights feeds Amazon DevOps Guru for RDS, which uses ML to detect anomalies, identify impacting SQL, and surface remediation recommendations automatically.
The long-term bet: richer, consolidated telemetry enables automated diagnosis and action, not just dashboards. A human reading a Performance Insights chart and opening a support ticket is being replaced by a system that observes query execution, detects regression, and surfaces a tuning recommendation, or applies one.
This trajectory is visible in the research community as well. Work published this month (Cost-Aware Optimization for Agentic Query Execution and AIM: Automated Index Management for SQL Databases) formalizes the patterns practitioners are beginning to deploy: agents that observe performance telemetry and take tuning actions autonomously.
What This Means for Autonomous Database Teams
For teams moving toward autonomous database management (AI agents that monitor query performance, detect regressions, and apply tuning actions without waiting for a human to notice), the choice of underlying observability infrastructure matters more than it did when a DBA was the primary consumer of the data.
Autonomous agents need:
- Structured, queryable execution data with retention long enough to detect trends. Seven days is not enough for most meaningful patterns.
- APIs, not console UIs: agents consume telemetry programmatically; interactive dashboards are a human artifact.
- Cost signal alongside performance signal to make intelligent trade-off decisions (the index that improves query time but triples scan cost is not obviously a win).
- Audit trails of what the agent observed, what it inferred, and what it acted on.
Standard mode's 7-day retention and reduced analysis capabilities create a bottleneck in this loop. Advanced mode's 15-month retention and richer telemetry are closer to what an autonomous agent needs, though the API surface for agentic consumption is still maturing.
The migration from Performance Insights to CloudWatch Database Insights is operational work with a hard deadline. The strategic question it surfaces is more durable: what does your database observability stack look like when the primary consumer of the telemetry is an AI agent, not a human?
At Datapace, autonomous database reliability and cost optimization is one of the four core pillars of our platform. If you are working through the Performance Insights migration and thinking about how your observability choices fit into a broader autonomous database strategy, we would like to help. If you are giving agents access to production data, book a call and we will walk through it on your stack.