AWS has set June 30, 2026 as the end of the road for the RDS Performance Insights console experience and paid retention. The successor is AWS Database Insights (in Amazon CloudWatch), which introduces fleet‑level visibility, on‑demand analysis, and a new vCPU/ACU‑based pricing model. If you depend on 30–730 days of history, execution plans, or guided diagnostics, this isn’t a “nice to have” change—you need a plan.
What changed—and when?
Here’s the timeline that matters for engineering managers, DBAs, and SREs:
• December 1, 2024: Amazon CloudWatch Database Insights became generally available for Aurora (PostgreSQL and MySQL).
• February 24, 2025: Database Insights added first‑class support for RDS engines, bringing instance‑level dashboards and SQL analytics to more fleets.
• 2025 feature cadence: Advanced mode gained historical OS process snapshots, customizable metric widgets, and expanded anomaly detection for on‑demand analysis.
• June 30, 2026: AWS will discontinue the Performance Insights console experience and flexible retention pricing. The Performance Insights APIs continue to exist; their costs roll up under CloudWatch alongside Database Insights.
Translation: standard seven-day history sticks around in the new world, but anything beyond that—and several console features you rely on—moves under Database Insights. Pretending this isn’t happening risks a silent downgrade to short‑term history.
Database Insights vs. Performance Insights: what’s different?
From hands-on rollouts, these are the differences your team will feel day one:
• Scope: Performance Insights focused on per‑instance DB load and top SQL. Database Insights adds fleet views, ties in Application Signals context, and centralizes metrics, logs, and query analytics.
• Modes: Standard mode is free with rolling seven days of the database load metric. Advanced mode unlocks deeper diagnostics (SQL analysis, execution plans on supported engines), on‑demand analysis with ML‑backed anomaly detection, and long‑term history.
• Pricing model: Instead of paying for retention months, you pay per monitored compute (roughly per vCPU‑hour for provisioned or per ACU‑hour for Aurora Serverless v2). That aligns spend with horsepower, but it also means forgetting to scope non‑prod can become a line item.
• Feature availability varies by engine: for example, SQL lock analysis is strongest on Aurora PostgreSQL; execution plans are supported on select engines (Aurora PostgreSQL, RDS for Oracle, and RDS for SQL Server). Confirm capabilities before you commit to SLAs.
One welcome upgrade is the on‑demand analysis experience. During a customer incident review, we selected a known outage window, and Database Insights surfaced spikes in database‑level counters and per‑SQL contributors alongside suggested next steps. It shaved hours off root cause analysis compared to stitching screenshots from multiple consoles.
How much will AWS Database Insights cost me?
Two realities can exist at once: Database Insights Advanced mode is both fairly priced for what it delivers and capable of surprising your budget if you lift‑and‑shift everything. The mental model is simple:
• Provisioned instances: roughly $0.0125 per vCPU‑hour.
• Aurora Serverless v2: roughly $0.003125 per ACU‑hour.
• Standard mode: free seven‑day history of DB load (good for lightweight estates, insufficient for seasonal performance analysis).
Quick calculator you can use in a planning doc:
Monthly Advanced cost ≈ SUM over instances: (vCPU × 0.0125 × hours in month). For a 2‑vCPU instance running 730 hours, that’s about $18.25. If you previously paid roughly $2–5 per month for long‑term retention via Performance Insights on that same box, this is a meaningful delta. The flip side is value: you’re buying richer telemetry, query‑level detail, and analysis workflows.
That’s why I recommend piloting Advanced mode on the few databases that truly matter—customer‑facing OLTP, top revenue paths, and the analytics systems that gate executive dashboards—while keeping non‑critical dev/test in Standard mode.
Is AWS Database Insights free?
Two parts to this “People also ask” classic:
• The feature exists in two modes. Standard mode is included (seven days of DB load). Advanced mode is paid, as described above.
• You don’t pay twice. After June 30, 2026, Performance Insights console pricing goes away; if you enable Advanced mode, those costs appear under CloudWatch. If you don’t, your instances default to Standard mode, and you lose retention beyond seven days in the console.
What happens if we do nothing by June 30, 2026?
Your RDS/Aurora instances will effectively fall back to Database Insights Standard mode in the console. You retain only seven days of DB load history there, and you won’t see Advanced features like execution plans or the on‑demand analysis report. Teams that depend on quarter‑over‑quarter trendlines or regression windows longer than a week will be flying partially blind.
What about the Performance Insights API?
The API isn’t going away. Post‑sunset, API usage costs will appear alongside Database Insights in CloudWatch billing. If you built custom dashboards that hammer DescribeDimensionKeys and GetResourceMetrics every few seconds, sanity‑check your call volume; you still get a healthy free tier, but bots can burn through it if you’re not careful.
Where AWS Database Insights shines
A few workflows the teams I advise have adopted quickly:
• Guided incident reviews: pull the on‑demand analysis for the exact outage window, screenshot the anomaly callouts, and paste the recommended actions into the postmortem template.
• Fleet health: a single place to answer “are we noisy neighbor bound, or is this one service regressing?” without hopping between CloudWatch, RDS, and app APM dashboards.
• Query‑first tuning: instead of arguing about CPU vs. IOPS, sort top SQL by load, grab the execution plan (if supported), and compare after an index change.
AWS Database Insights migration plan (6 steps)
Here’s the pragmatic rollout I’ve used with platform teams. Budget half a day to draft and a week to pilot.
1) Inventory and classify
Export all Aurora and RDS instances with engine, version, vCPU/ACU, and a business criticality tag. Mark the ones with strict SLOs. Partition into tiers: Tier 1 (customer‑facing OLTP), Tier 2 (internal but latency‑sensitive), Tier 3 (batch, dev/test).
2) Map features to engines
Confirm Advanced mode features you rely on by engine family. If your team expects execution plans or lock graphs, validate support on that engine and version. Set expectations early to avoid promising a capability that isn’t there on day one.
3) Model costs with tags
Estimate Advanced mode for Tier 1 only. Use the simple formula above. In Cost Explorer, filter for CloudWatch usage types like DatabaseInsights‑vCPU‑Hours to see pilot spend. Tag new enablements with Environment, Owner, and CostCenter so Finance can attribute changes cleanly.
4) Pilot safely
Pick two or three representative Tier 1 instances. Enable Advanced mode and capture a baseline week of telemetry. Validate: (a) fleet dashboards show the right alarms, (b) on‑demand analysis runs within minutes and is useful, (c) query analytics reflects your ORM and hand‑tuned SQL truthfully.
5) Retire overlapping dashboards
Identify and deprecate PI‑centered runbooks as you move teams to Database Insights. Reduce custom polling of PI APIs; if you keep them, throttle or cache responses to avoid unnecessary calls. Update runbooks to point to the new on‑demand analysis workflow.
6) Roll out by tier
Move Tier 1, reassess cost/perf, then decide which Tier 2 systems merit Advanced mode. Leave Tier 3 in Standard. Calendar a reminder in early June 2026 to confirm no critical instance is stuck on Standard with only seven days of history.
Gotchas and edge cases from the field
• Non‑prod sprawl: Enabling Advanced mode across dozens of ephemeral dev DBs is a tax you don’t need. Scope to production and a few high‑signal staging environments.
• Engine mismatches: Teams assume execution plans everywhere. They’re not. Validate engine support (Aurora PostgreSQL is the safest bet for the richest set right now).
• Version lag: Some features depend on engine and minor version. Pin upgrades into your DB maintenance calendar if a capability is a must‑have.
• Phantom costs: A Grafana board that hammers PI APIs every 2–5 seconds can tip you over the free tier. Use server‑side caching or widen the polling interval.
Governance and tagging: keep Finance happy
Observability can go from tidy line item to “why is CloudWatch up 27%?” overnight. A few controls that work:
• Tag policy: Require Environment, Owner, CostCenter, and DataClass on all DBs. Enforce in CI/CD or via Service Catalog.
• SCP/Guardrails: Block Advanced mode in non‑prod accounts, or require an approval via a change request template with an explicit monthly estimate.
• Cost monitors: Create Cost Anomaly Detection monitors scoped to DatabaseInsights‑* usage types and alert the owning Slack channel.
• Quarterly reviews: Decide whether any Advanced‑mode DB can drop back to Standard with saved dashboards and external long‑term storage.
How this fits your broader AWS cost and performance playbook
Database Insights is one piece of a bigger optimization narrative. If you’re re‑baselining budgets, this is a perfect time to consider other high‑leverage moves. For example, review our guidance on who should switch to CloudFront flat‑rate pricing and how to cut NAT Gateway cost while simplifying VPCs. Both pair nicely with a clean observability plan. If you want help designing the rollout and guardrails, see what we do for engineering teams or talk to us.
People also ask
Do I need Advanced mode on every database?
No. Put Advanced on revenue‑critical workloads and anything with hard latency or throughput SLOs. Keep the rest on Standard and use targeted long‑term storage (for example, export query stats weekly to S3) if you need historical breadcrumbs without full Advanced spend.
Can I keep using the Performance Insights console until the deadline?
Yes, but that’s procrastination in disguise. Turn on a pilot now and train your on‑call rotation on the Database Insights workflows so the switchover is boring when the date arrives.
Will this break my existing alarms?
Most CloudWatch metric alarms continue to work. But you’ll get more out of Database Insights by embracing its recommended alarms and fleet dashboards. During migration, run both sets for a sprint, then consolidate.
How do I export long‑term data without paying for Advanced?
If you truly can’t fund Advanced on an instance, schedule exports of key metrics and SQL stats to S3 and visualize in Athena/QuickSight. It’s more DIY, and you won’t get on‑demand analysis, but it preserves history beyond seven days.
A simple, defensible rollout checklist
Use this in your change request:
• Decision doc: which DBs get Advanced vs. Standard, with owner and rationale.
• Cost table: instance → vCPU/ACU → estimated monthly cost → tag mapping.
• Runbook updates: add Database Insights links, on‑demand analysis steps, and escalation paths.
• Training: 45‑minute internal workshop to walk through an incident scenario in Database Insights.
• Guardrails: SCP to block Advanced in non‑prod; Cost Anomaly monitor scoped to Database Insights usage types.
• Calendar hold: June 15, 2026 verification that all Tier 1 DBs are on Advanced and Tier 2/3 are intentionally Standard.
Let’s get practical: enabling AWS Database Insights without drama
When you enable Advanced mode on a candidate instance, immediately open the database’s dashboard and verify three things: (1) load and CPU charts are populated; (2) the SQL tab reflects expected top statements; (3) on‑demand analysis completes and flags the right anomalies for a known traffic spike. If any of those fail, check engine/version support and IAM permissions first.
If your team is modernizing adjacent services, this is a good time to tackle performance plumbing elsewhere too. For example, if you serve latency‑sensitive APIs, consider pairing this with the playbook we published on API Gateway response streaming to shave tail latency while you improve DB visibility.
What to do next
• This week: inventory DBs, pick three Tier 1 candidates, and enable Advanced mode. Tie spend to tags and set one Cost Anomaly alert.
• Next two weeks: train the on‑call rotation using a real incident window and the on‑demand analysis flow. Update runbooks and alarms.
• Next month: expand to the rest of Tier 1, decide Tier 2 eligibility, and freeze Tier 3 in Standard. Remove redundant PI dashboards to curb API noise.
• By June 1, 2026: confirm no critical DB is stuck on Standard; archive any long‑term data you’d lose; freeze the migration.
AWS Database Insights isn’t just a replacement—it pushes observability closer to where you actually make decisions during incidents. Treat the migration as a chance to simplify dashboards, make budgets predictable, and sharpen your performance story before the June 30, 2026 deadline.
