If you run RDS or Aurora in production and you have not yet touched your monitoring configuration, you have five days.
On June 30, 2026 (this Monday), AWS is deprecating the Performance Insights console experience as a standalone product. The API survives; the console, flexible retention periods, and the pricing model you have been running under do not. What replaces them is CloudWatch Database Insights, a newer and in some ways more capable monitoring tier, but the migration is not automatic, the cost math is not straightforward, and if you do nothing before the deadline, you will quietly lose access to features you may not realize you depend on.
This post is a practical guide. Here is what changes, what you lose if you wait, how to migrate, and how to think about the cost implications across a typical RDS/Aurora fleet.
What Is Happening and Why
AWS has been consolidating its database observability 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 and Advanced), and a pricing model tied to vCPU count rather than flat retention fees.
AWS's official transition guide and the pganalyze technical breakdown provide the authoritative detail. Here is the operational summary:
What remains after June 30:
- The Performance Insights API (no change, no pricing change)
- Core load monitoring data for instances already using Performance Insights
What stops working if you do not migrate:
- The Performance Insights console experience
- Flexible data retention beyond 7 days in the Standard tier
- On-demand analysis in the RDS console
- Execution plan capture (available only in Database Insights Advanced; it did not exist in Performance Insights at all)
What happens by default if you do nothing:
AWS migrates DB instances using Performance Insights to Database Insights Standard mode automatically. In Standard mode you get 7-day data retention at no additional cost. If you were using extended retention windows (30 days, 6 months, 12 months) under the old pricing model, that history window disappears without action on your part.
The Two Tiers, Compared
Database Insights Standard
- 7-day data retention
- Core DB load monitoring: Average Active Sessions, wait events, top SQL
- No execution plan capture, no fleet-level monitoring, no lock diagnostics
- No additional cost beyond existing RDS pricing
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: approximately $9 per vCPU per month for provisioned instances; approximately $2.50 per ACU per month for serverless
Execution plan capture in Advanced is worth calling out specifically. Performance Insights did not offer this; it was a gap in the old product. Upgrading to Advanced gives you a capability that did not previously exist, making Advanced the right choice for any team doing serious query performance investigation.
Cost Implications Across a Typical Fleet
Under old Performance Insights paid tiers, a 90-day retention window on a 4-vCPU instance ran approximately $0.02/vCPU-hour, roughly $58/month per instance. A 30-instance fleet with 4 vCPUs each and 90-day retention ran approximately $1,740/month.
Under Database Insights Advanced at $9/vCPU/month, that same fleet costs $1,080/month, which is cheaper, with better features, and 15-month retention instead of 90 days.
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: on large instances (32+ vCPUs), Database Insights Advanced can exceed $300/month per instance. For RDS fleets with large nodes, the cost conversation is material and worth having before June 30 rather than after.
Your Five-Day Migration Checklist
Day 1-2: Audit your current 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.
Day 2-3: 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. Sum it against your current Performance Insights spend. In most cases the math favors Advanced for production nodes below 32 vCPUs.
Day 3-4: 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.
Day 4-5: Validate and update runbooks
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 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.
Before June 30: Export historical data you want to keep
Historical data from Performance Insights does not automatically transfer to Database Insights. AWS retains Performance Insights data according to the retention period configured before migration, but console access ends June 30. If you need to audit historical query performance from before the migration, export relevant data now via the Performance Insights API:
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.
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 observability stack for a production RDS/Aurora fleet actually look like, and how much of it should your team be building manually?
The migration from Performance Insights to Database Insights 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 (new in Database Insights Advanced and absent in Performance Insights), 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 this year, 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.
AWS took a step in that direction with Database Insights Advanced. The full autonomous database reliability stack is the problem Datapace is building toward: monitoring tells you what happened; optimization determines what happens next.
The deadline is June 30. The checklist above gets you there. The larger question of what your database reliability posture looks like on July 1 is the one worth answering this week.
Talk to us about Datapace's autonomous database reliability layer, which goes beyond monitoring to continuous optimization and cost reduction.