On July 31, 2026, AWS retires the Performance Insights console (the deadline was originally announced as June 30, then moved a month). The API survives, and flexible retention (1 to 24 months) carries into CloudWatch Database Insights Standard mode at the same price. The console, on-demand analysis, and execution plan capture do not: the console redirects to CloudWatch, and the other two become Advanced-mode features.
If you take no action before the deadline, AWS defaults your instances to Database Insights Standard mode with your existing retention period intact. What Standard does not carry over: on-demand analysis, execution plan capture, and the console workflows your on-call rotation navigates by memory.
This post is a practical guide: what changes, what moves behind Advanced mode, how to tier your fleet, the mistakes teams keep making, and what it costs across a typical RDS/Aurora fleet.
What Changes on July 31 (and What Survives)
AWS has been consolidating its database monitoring tooling under CloudWatch for several years. Performance Insights, launched in 2018, was a separate product with its own console, data model, and pricing. CloudWatch Database Insights is the replacement, integrated into CloudWatch, with two service tiers: Standard, which keeps Performance Insights retention pricing, and Advanced, which is metered per vCPU.
AWS's official transition guide and the pganalyze technical breakdown provide the authoritative detail. Here is the operational summary:
What remains after the deprecation:
- The Performance Insights API (no change, no pricing change)
- Core load monitoring data for instances that were already using Performance Insights
- Flexible retention periods (1 to 24 months) and their pricing, preserved in Database Insights Standard mode
What stops working on July 31:
- The Performance Insights console experience (it redirects to CloudWatch Database Insights)
- On-demand analysis outside of Database Insights Advanced
- Execution plan capture (previously available for RDS for Oracle and SQL Server) outside of Advanced
What happens by default:
AWS moves DB instances using Performance Insights to Database Insights Standard mode automatically, with the existing retention period configured. The default preserves your data window. What it does not preserve is on-demand analysis and plan capture, which become Advanced-only.
The Two Tiers, Compared
Database Insights Standard
- 7-day data retention free; paid flexible retention (1 to 24 months) at existing Performance Insights pricing
- Core DB load monitoring: Average Active Sessions, wait events, top SQL
- No execution plan capture, no fleet-level monitoring, no lock diagnostics
Database Insights Advanced
- 15-month data retention
- All Standard capabilities, plus: execution plan capture, lock diagnostics, fleet-level monitoring across instances, on-demand analysis
- Pricing: $0.0125 per vCPU-hour (about $9 per vCPU per month) for provisioned instances; $0.003125 per ACU-hour for Aurora Serverless v2
Execution plan capture is worth calling out specifically. In Performance Insights it existed only for RDS for Oracle and SQL Server; after July 31 it is exclusive to Advanced. Plan history is what your DBA or on-call engineer reaches for during regression diagnosis: what plan was this query using three weeks ago, before the performance drop? Without it, retroactive analysis means reconstructing context from logs rather than examining captured plan data.
Advanced Costs About $9 Per vCPU Per Month
Database Insights Advanced is metered at $0.0125 per vCPU-hour (us-east-1), roughly $9.13 per vCPU per month. A 4-vCPU production instance runs about $36.50/month; a 30-instance fleet of 4-vCPU nodes lands near $1,095/month. Retention alone does not justify that spend: Standard keeps flexible paid retention at the old Performance Insights pricing, so you upgrade to Advanced for execution plans, lock diagnostics, and fleet-level monitoring, not for history.
The cost trap to avoid: upgrading to Advanced on instances where you do not need fleet monitoring or execution plan capture. For dev and staging environments, Standard is almost always sufficient. For production databases running complex query workloads, Advanced pays for itself in one prevented performance incident.
From the pganalyze analysis: a 32-vCPU instance meters out at $292/month on Advanced, and a db.r7g.8xlarge came to $490/month once CloudWatch Logs exports were included. For RDS fleets with large nodes, the cost conversation is material.
The Migration Checklist
Step 1: Audit your fleet
Identify which instances have Performance Insights enabled and what retention periods are configured:
aws rds describe-db-instances \ --query 'DBInstances[?PerformanceInsightsEnabled==`true`].[DBInstanceIdentifier,PerformanceInsightsRetentionPeriod]' \ --output table
For Aurora clusters:
aws rds describe-db-clusters \
--query 'DBClusters[*].{Cluster:DBClusterIdentifier,Members:DBClusterMembers[*].DBInstanceIdentifier}' \
--output table
Capture instance ID, current retention period, environment (production vs. dev/staging), and vCPU count. This becomes your change record and cost calculation input.
Step 2: Decide Standard vs. Advanced per instance tier
Use this decision matrix:
- Production + query performance investigation + execution plan visibility needed: Advanced
- Production + basic load monitoring is sufficient: Standard
- Dev/staging: Standard
- Ephemeral or batch workloads with sub-7-day cycles: Standard or disable
Calculate the cost delta for each production instance you plan to move to Advanced and sum it against your current Performance Insights spend. Treat Advanced as a feature upgrade, not a cost save: it is metered per vCPU and climbs fast on large nodes.
Two checks worth doing at this stage. First, verify region coverage: Database Insights availability and feature parity is not uniform across all AWS regions, so confirm Advanced mode is available everywhere you run RDS before assuming the upgrade path is consistent. Second, if you are already running a third-party monitoring agent alongside the AWS tooling (pganalyze, Datadog, New Relic), this transition is a natural moment to consolidate, and it surfaces a strategic question: do you want database monitoring tied to the AWS console and CloudWatch, or a portable multi-cloud monitoring stack?
Step 3: Enable Database Insights on production instances
Via the AWS CLI (Advanced, 15-month retention):
aws rds modify-db-instance \ --db-instance-identifier your-instance-name \ --enable-performance-insights \ --performance-insights-retention-period 465 \ --no-apply-immediately
Retention period values: 7 = Standard (7 days), 465 = Advanced (15 months).
Apply with --no-apply-immediately for production instances to schedule changes in the next maintenance window. For dev/staging, use --apply-immediately.
For Aurora cluster members, run modify-db-instance against each cluster member individually. Cluster-level modification does not cascade to instance-level monitoring settings.
Step 4: Validate and update runbooks, IaC, and alerting
After enabling Database Insights, confirm the CloudWatch console shows the new Database Insights view for each migrated instance. Verify existing CloudWatch alarms and dashboards still fire correctly. The API is unchanged, but any console-specific alert workflows built in the old Performance Insights UI need to be recreated in CloudWatch.
Update any Terraform, CloudFormation, or CDK that references Performance Insights resource names or metric namespaces, and re-check alerting thresholds where metric names or dimensions changed. Then run a synthetic incident drill to confirm on-demand analysis is accessible in the new console experience before you need it in production.
Update on-call runbooks: the "Performance Insights" tab in the RDS console is replaced by the "Database Insights" view in CloudWatch. Anyone on your on-call rotation who navigates by memory needs to know the path changed before they are paged at 2am.
Step 5: Export historical data you want to keep
Console access ends July 31, but the API survives, and AWS states your configured retention period carries into Standard mode. Treat exports as cheap insurance anyway: if you need to audit historical query performance from before the cutover, pull the relevant windows via the Performance Insights API while they are still inside your retention period:
aws pi get-resource-metrics \
--service-type RDS \
--identifier db:your-instance-name \
--metric-queries '[{"Metric":"db.load.avg"}]' \
--start-time 2026-01-01T00:00:00Z \
--end-time 2026-06-29T23:59:59Z
The DoiT migration guide has detailed API examples for bulk data export across a fleet.
Common Migration Mistakes
Assuming Standard mode is equivalent. If your incident response process relies on on-demand analysis or execution plan capture (and most mature teams' processes do), the automatic migration to Standard removes workflows you had not documented as dependencies. Audit what your engineers actually reach for during incidents, then tier accordingly.
Leaving the auto-migrated default in place. The instances AWS moves to Standard on July 31 do not get a cost-benefit analysis; they get a default. Run the decision matrix above per instance rather than accepting the landing zone.
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 Bigger Picture: What This Reveals About Database Reliability
The Performance Insights deprecation is a useful forcing function for a conversation many database engineering teams have been deferring: what does a complete monitoring stack for a production RDS/Aurora fleet actually look like, and how much of it should your team be building manually?
The migration itself is a one-time configuration change. The harder problem it surfaces is durable: as database fleets scale and query workload complexity grows, manual monitoring and reactive performance tuning do not scale with them.
Execution plan capture, combined with workload-level cost attribution and autonomous index recommendations, is the direction the field is moving. The STRATUS research paper on multi-agent SRE published in 2025, and papers on agentic query cost optimization, reflect the same vector: autonomous systems that detect anomalies, identify root causes, recommend optimizations, and execute fixes within guardrails are the next layer above monitoring. That layer only works if every action those systems take is policy-checked, approved, and audited.
AWS took a step in that direction with Database Insights Advanced. Monitoring tells you what happened; the autonomous operations layer determines what happens next. Datapace is the context layer and security gateway for that step: it knows what's there, what it means, how it connects, and it lets teams run AI operations on production databases safely, with DBAs in control.
The checklist above closes out the migration. The larger question of what your database reliability posture looks like now that it is done is the one worth answering this quarter. If you are working through it, book a call and we will walk through it on your stack.