Skill 62 · Amazon Aurora PostgreSQL
Subchapter 62.29
references/upgrade-planning-instructions.mdMarkdown6 KBView on GitHub
Guide customers through Aurora PostgreSQL major and minor version upgrades. Identifies the cluster, recommends target versions (latest vs LTS), runs live prechecks, flags query-plan regressions, and surfaces pre- and post-upgrade checklists. Major version upgrades are blocked — see SKILL.md Safety guidance. This reference helps plan the upgrade.
Execute commands using available tools from the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI or shell when the MCP server is not available.
User mentions: upgrade Aurora cluster, what version should I upgrade to, pre-upgrade checklist, post-upgrade steps, Aurora LTS, upgrade prechecks, Aurora PostgreSQL upgrade, or major/minor version upgrade.
Mode A — Advisory (no cluster named): User asks a general question like “what version should I upgrade to?” or “what’s the LTS version?” without specifying a cluster. Skip directly to LTS recommendation (see “Mode A workflow” below). Do NOT ask for cluster ID and region first — recommend the LTS version with rationale, then offer to run the live workflow if they want a cluster-specific assessment.
Mode B — Cluster-specific (cluster named): User names a cluster identifier or asks you to plan an upgrade for a specific cluster. Run the full workflow (Tasks 1–8) with live AWS calls. Tasks are split across:
When the user reports a completed upgrade and asks what to check now, route to post-upgrade-validation.md (must-surface Aurora items + immediate cluster-state checks) and post-upgrade-detail.md (statistics refresh, extension updates, plan verification, parameter-group-family migration, snapshot rollback window, monitoring window).
When the user asks “what version should I upgrade to?” with their current version (e.g., “I’m on 14.9”) but no cluster ID:
Mode A does NOT need cluster identifier, region, or live AWS calls. It is general guidance, version-independent. For the authoritative current-LTS table and the LTS/latest trade-offs, see lts-recommendation.md.
Cluster not found. Check region and cluster identifier. For Global Databases, use describe-global-clusters with the global cluster identifier.
Engine version shows -limitless. Aurora Limitless. Upgrade paths are separate — only offer -limitless target versions and note the model differs.
Precheck queries time out via SSM. Increase the SSM timeout, or switch to RDS Data API if enabled. Large schemas can take minutes for information_schema queries.
RDS Proxy compatibility unclear. Check target version release notes. If unclear, test on a snapshot-restored clone with the proxy attached before production.
User wants to roll back after a successful upgrade. Rollback requires snapshot restore — no in-place downgrade. If the cluster is functioning but has a regression, debug it rather than roll back. See the post-upgrade checklist for regression-hunting steps.