RDS minor version auto-upgrades are a double-edged sword, offering convenience at the cost of absolute control, but there are ways to manage them.
Let’s see RDS minor version auto-upgrades in action. Imagine you have a PostgreSQL 13.4 database. AWS, as part of its managed service, will automatically apply minor patches and bug fixes to keep your instance secure and stable. This might mean your rds.version gradually moves to 13.5, then 13.6, and so on, without you lifting a finger. You can monitor this process through CloudWatch events and RDS events.
The core problem RDS auto-upgrades solve is operational overhead. For many, the burden of tracking, testing, and applying minor database patches is a significant drain on resources. By automating this, AWS allows teams to focus on higher-value tasks. Internally, when a new minor version is released by the database engine vendor (e.g., PostgreSQL Global Development Group), AWS tests it rigorously. Once validated, they schedule its rollout to RDS instances. This rollout typically happens during a maintenance window you’ve configured for your instance. AWS orchestrates the upgrade by applying the new patch to your instance. For most minor version upgrades, this involves a brief downtime, usually measured in minutes, during which the database instance is restarted.
The primary lever you control is the Maintenance Window. This is a daily, one-hour (or longer) period you specify during which RDS is allowed to perform automated maintenance, including minor version upgrades. You can set this window via the AWS Management Console, CLI, or API. For example, you might set your maintenance window to sun:03:00-sun:04:00 (UTC) to minimize disruption during off-peak hours. You can also explicitly disable auto-minor version upgrades for a specific instance if you need complete control over when these changes occur. This is done by setting the auto_minor_version_upgrade parameter to false in your DB instance’s parameter group.
Here’s how you’d check your current setting using the AWS CLI:
aws rds describe-db-instances --db-instance-identifier your-db-instance-name --query "DBInstances[0].AutoMinorVersionUpgrade"
This command will return true or false. To disable it, you’d modify your DB parameter group. First, find your parameter group:
aws rds describe-db-instances --db-instance-identifier your-db-instance-name --query "DBInstances[0].DBParameterGroups[0].DBParameterGroupName"
Then, modify the parameter group:
aws rds modify-db-parameter-group --db-parameter-group-name your-parameter-group-name --parameters "ParameterName=auto_minor_version_upgrade,ParameterValue=false,ApplyMethod=immediate"
Note that changing this parameter might require a reboot of your DB instance for the change to take effect, depending on the specific parameter and database engine. Always check the RDS documentation for the exact behavior.
Beyond the maintenance window, you can also monitor upcoming upgrades. RDS emits events for scheduled maintenance. You can subscribe to these events via SNS or check the RDS Events section in the console. For instance, you might see an event like RDS-EVENT-0005: The minor version of DB instance 'your-db-instance-name' will be upgraded. This gives you a heads-up to prepare your applications.
The most surprising thing about auto-upgrades is how they interact with read replicas. If you have read replicas, an auto-minor version upgrade on the primary instance will not automatically upgrade the read replicas. You’ll need to perform those upgrades manually or configure auto-upgrades separately for each replica, which can lead to version drift if not managed carefully.
The next concept to grapple with is major version upgrades, which are not automated and require a more deliberate, planned approach.