Upgrade Pre Checklist

Create a snapshot before starting. This is your rollback safety net regardless of upgrade method:

Step 2: Check Automated Backup Status

Automated backups are NOT required for in-place upgrades. However:

• If automated backups ARE enabled, RDS automatically takes a pre-upgrade snapshot before starting the upgrade. This is a safety net you get for free.
• If automated backups are NOT enabled, RDS skips the pre-upgrade snapshot and proceeds directly. You lose that automatic rollback point.
• Automated backups ARE required for Blue/Green deployments (replication depends on them).

If 0 and you want the automatic pre-upgrade snapshot (recommended):

Step 3: Check for Pending Maintenance

Pending maintenance actions can block upgrades. Apply them first:

Step 4: Run the RDS Pre-Upgrade Validation

For MySQL 5.7 to 8.0 major upgrades, RDS automatically runs a prechecks script as part of the upgrade process. If prechecks fail, the upgrade is aborted and the instance stays on the current version.

You can preview what the prechecker will find by running it yourself before initiating the upgrade. Connect to the database and run:

If this procedure is not available, the key checks the prechecker runs are:

• Reserved keywords used as identifiers (table names, column names)
• Orphaned InnoDB tables (.frm without .ibd)
• Tables using non-native partitioning
• Triggers or events with null definers
• Incompatible data types or character sets

Review the output and fix any issues BEFORE initiating the upgrade.

Step 5: Check for Reserved Keywords

MySQL 8.0 added new reserved keywords. If your schema uses any of these as unquoted identifiers, the upgrade prechecker will flag them:

CUME_DIST, DENSE_RANK, EMPTY, EXCEPT, FIRST_VALUE, GROUPING, GROUPS, JSON_TABLE, LAG, LAST_VALUE, LATERAL, LEAD, NTH_VALUE, NTILE, OF, OVER, PERCENT_RANK, RANK, RECURSIVE, ROW, ROWS, ROW_NUMBER, SYSTEM, WINDOW

Fix by quoting with backticks or renaming before the upgrade.

Step 6: Create a Target Parameter Group (Optional)

If you don’t create a custom parameter group, RDS will assign the default parameter group for the target version family (e.g., default.mysql8.0). This uses MySQL 8.0 defaults which differ from 5.7 in several ways.

If you want to preserve current behavior, create a custom parameter group:

Key parameters to preserve (MySQL 5.7 to 8.0):

Note: query_cache_type and query_cache_size are removed in 8.0 — no parameter to set. If your app relied on query cache, handle at the application layer.

Step 7: Test on a Snapshot-Restored Instance

Restore your snapshot and upgrade the test instance to validate:

Then upgrade the test instance:

After the test instance is upgraded and available:

1. Validate database operations — connect, run key queries, check schema integrity
2. Verify application connectivity — point your application (or a test instance of it) at the upgraded test database and confirm the application driver works correctly with the new engine version. Auth plugin changes (e.g., caching_sha2_password in MySQL 8.0), TLS requirements, and connection string parameters may behave differently.

Step 8: Consider Blue/Green Deployment

For production instances, Blue/Green is safer than in-place:

• Creates a staging copy on the target version
• Keeps it in sync via replication
• Switchover with typically under 1 minute of downtime

Requirements: automated backups enabled, binlog_format=ROW (MySQL/MariaDB), engine version supports Blue/Green (MySQL 5.7+, MariaDB 10.4+, PostgreSQL 12.7+).

Step 9: Review Target Version Release Notes

Before upgrading, review the release notes for the target version to understand behavioral changes, new features, and deprecations. Key changes to watch for are called out below by engine.

MySQL (e.g., 5.7 → 8.0):

• New data dictionary (no more .frm files)
• New TempTable engine replaces MEMORY for internal temp tables
• GROUP BY no longer implicitly sorts results
• Query cache removed entirely
• Default auth plugin changed to caching_sha2_password
• Release notes: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/ (opens in a new tab)

MariaDB (e.g., 10.6 → 10.11 or 11.4):

• Each major version introduces new SQL features, optimizer changes, and storage engine updates
• Check for deprecated features being removed in the target version
• Release notes: https://mariadb.com/kb/en/release-notes/ (opens in a new tab)

PostgreSQL (e.g., 14 → 15 or 16):

• Each major version refines the planner cost model, which can change query plans
• New features like Memoize (PG 14), work_mem changes (PG 15), subquery decorrelation (PG 16)
• Extension compatibility may change between major versions
• Release notes: https://www.postgresql.org/docs/release/ (opens in a new tab)

You SHOULD read the “Incompatible Changes” or “Removed Features” section of the target version’s release notes before proceeding.

Step 10: Notify Stakeholders

Before executing:

• Notify application teams about the maintenance window
• Confirm connection strings don’t hardcode the engine version
• Verify application compatibility with the target version
• For MySQL 5.7 to 8.0: warn about GROUP BY implicit sort removal, strict mode default, auth plugin changes