All Products
Search

This Product

    ApsaraDB RDS:Upgrade the major engine version and RDS edition of an instance

    Document Center

    ApsaraDB RDS:Upgrade the major engine version and RDS edition of an instance

    Last Updated:May 29, 2026

    The capabilities of an ApsaraDB RDS for SQL Server instance vary with the instance's major engine version (SQL Server version) and RDS edition. For better performance and scalability, you can upgrade your instance to a higher version and edition. For example, you can upgrade the major version of an instance from SQL Server 2019 Standard Edition to SQL Server 2022 Standard Edition, or upgrade the instance edition from Basic Edition to High-availability Edition.

    Background information

    RDS for SQL Server offers instances in three editions, each with different features and advantages.

    • Basic Edition instances do not have a secondary instance for hot standby. This may cause extended downtime if an instance fails or during tasks like specification changes or version upgrades.

    • High-availability Edition instances use a classic high-availability architecture with a primary instance and a secondary instance. Data from the primary instance is synchronized to the secondary instance semi-synchronously or asynchronously. If the primary instance fails, the system automatically fails over to the secondary instance.

    • Cluster Edition instances are based on the Always On technology of SQL Server, which decouples compute from storage. This edition lets you create one or more read-only instances to implement read/write splitting, ideal for high read volumes.

    Usage notes

    • Upgrades of the major engine version, edition, and instance type are irreversible. The upgrade rules are as follows:

      Upgrade rules

      Upgrade item

      Upgrade rule

      Upgrade database major engine version (SQL Server)

      • Standard Edition → Enterprise Edition

      • Standard Edition → Enterprise Cluster Edition

      • Web Edition → Standard Edition

      • Web Edition → Enterprise Edition

      • Web Edition → Enterprise Cluster Edition

      Note

      To upgrade from Web Edition to Enterprise Edition or Enterprise Cluster Edition, you must first upgrade to Standard Edition.

      Upgrade RDS edition

      You can only upgrade to a higher edition. The editions, from lowest to highest, are: Basic Edition < High-availability Edition < Cluster Edition. Downgrades are not supported.

      Upgrade instance family or instance type

      You can upgrade to the same or a higher instance family. Check the console for available options.

      The instance families, from lowest to highest, are: Shared < General-purpose < Dedicated. Downgrading to a lower instance family is not supported.

      Note

      • You cannot directly upgrade an instance from a shared instance type in the High-availability Edition to a dedicated instance type in the Cluster Edition.

      • If the target instance family is not available in the console, create a new instance in the target instance family and then migrate data from the original instance to the new instance.

      Warning

      • Because upgrades are irreversible, we recommend that you first create a pay-as-you-go or serverless target instance to test compatibility.

      • During the upgrade, do not modify instance metadata. This can cause data inconsistencies after the upgrade. Metadata modification operations include, but are not limited to, adding or deleting databases, or changing the recovery model of a database.

    • The upgrade will involve a cross-host migration, which will clear the host account and any programs or files, such as SSIS, SSAS, and SSRS, on the original host. You must migrate or back up your data in advance.

      Important

      In most cases, minor engine version updates do not cause compatibility issues. However, they may cause changes in functionality. We recommend that you check the SQL Server cumulative updates (CUs) released by Microsoft to verify whether the SQL Server kernel is updated.

    Limitations

    The following instances do not support database version upgrades:

    Impacts

    • Once started, the upgrade process cannot be canceled, and it cannot be rolled back after completion.

    • Your existing settings, such as the instance name, port, tags, and database accounts, remain unchanged after the upgrade.

    • The upgrade duration depends on factors such as the data volume of your instance. For more information, see the FAQ section in this topic.

    • The upgrade involves a network switchover, which causes a service interruption that can last up to 20 minutes. For more information, see the FAQ section in this topic. Ensure that your application has an automatic reconnection mechanism.

    • During the upgrade, the process migrates the instance's underlying resources, which causes the virtual IP (VIP) address to change. To ensure business stability and continuity, you must use the internal or public endpoint of the RDS instance to connect to your application. Do not use the resolved IP address. The RDS endpoint is a dynamic domain name with automatic routing capabilities that seamlessly adapts to backend IP changes.

    • If you choose to switch within the maintenance window, regular instance backups are disabled from when you submit the upgrade task until the migration is complete.

    • Clear the DNS cache on your client. If your client is a JVM-based application, we recommend setting the TTL in the JVM configuration to 60 seconds or less. This ensures that when the VIP address of the endpoint changes, the application can obtain the new VIP address by re-querying the DNS.

      Note

      The following methods for setting the TTL in the JVM are for your reference:

      • To set the TTL for all JVM-based applications, set the networkaddress.cache.ttl parameter in the $JAVA_HOME/jre/lib/security/java.security file to 60.

      • To set the TTL for only a local application, set java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); in the application's initialization code before any network connections are established, specifically before the first call to InetAddress.getByName().

    • If you have an ongoing Data Transmission Service (DTS) task, you must reconfigure and restart the task after the upgrade.

    Billing

    For information about the fees for upgrading the version, see change specifications.

    Procedure

    1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

    2. On the Basic Information page, in the Configuration Information section, click Upgrade Version. In the dialog box that appears, click OK.

      Note

      If Upgrade Version is not displayed, check whether your instance meets the upgrade requirements.

    3. On the Upgrade Engine Version page, modify the configuration. The following table describes the key parameters. For information about other parameters, see Procedure.

      Note

      Some instances may have restrictions on the available versions and editions during an upgrade. For more information, see the Usage notes and Limitations sections in this topic.

      Parameter

      Description

      Upgrade To

      The available options for Edition and Instance Type change based on the target version you select. For more information, see Upgrade rules.

      Edition

      Select the target edition:

      • Basic Edition: A single-node architecture with compute and storage decoupled.

      • High-availability Edition: A classic high-availability architecture with a primary and a secondary instance, providing balanced performance.

      • Cluster Edition: A high-availability architecture with one primary and multiple secondary instances. The secondary instances are accessible for read operations.

      Instance Type

      Each instance type has a specific vCPU count, memory size, maximum number of connections, and maximum IOPS.

      Switching Time

      • Switch Immediately After Data Migration: The migration and switchover start immediately.

      • Switch Within Maintenance Window: The migration starts immediately, and the switchover occurs during the configured maintenance window.

    4. Click Pay Now. In the dialog box that appears, click OK.

      The status of the instance changes to Upgrading/Downgrading > Upgrading Across Networks. When the status of the instance changes to Running, the upgrade is complete. The time required depends on the amount of data. Please wait patiently.

    FAQ

    Can I change the instance configuration, such as the instance type, during a major version upgrade?

    No, you cannot change the instance configuration during a major version upgrade. You must wait until the upgrade is complete to perform other operations.

    Are automatic major version upgrades supported?

    Automatic major version upgrades are not supported.

    How long does a major version upgrade take?

    Estimated time

    The following table provides an estimated time range for upgrading the major version of an instance. Note that the backup and restore speeds are based on the uncompressed data size.

    Note

    Because instances that run the Web Edition do not support backup compression, backup efficiency is lower. The backup and restore speeds may drop below 100 GB/hour.

    Operation

    Required

    Estimated time

    Notes

    Create and configure new instance

    Yes

    10–15 minutes

    The time required depends on the edition and instance type selected for the upgrade.

    Perform a full backup of the instance

    No

    200 GB/hour

    • Based on the full backup policy, if a full backup has not been performed within the last 36 hours, the system performs one during the major engine version upgrade to balance the time spent restoring the full backup and applying transaction logs.

      We recommend that you manually perform a full backup before the upgrade, or initiate the upgrade within 36 hours after an automatic full backup completes. This reduces the total upgrade time.

    • The backup speed may vary by region and time of day.

    • For a more accurate estimate of backup and restore performance, refer to the data size and duration of your most recent full backup.

    Restore the full backup on the target instance

    Yes

    200 GB/hour

    None

    Perform an incremental transaction log backup on the source instance

    Yes

    200 GB/hour

    An additional 2 minutes of overhead may be required before and after the incremental log backup for tasks such as preparation, finalization, and resource allocation.

    Apply the incremental transaction log backup on the target instance

    Yes

    200 GB/hour

    An additional 2 minutes of overhead may be required before and after applying the incremental log backup for tasks such as backup consistency verification.

    Database recovery

    Yes

    Typically within 2 minutes

    • Resource consumption: Applying incremental transaction logs is a resource-intensive operation. For small instance types (for example, 2 vCPUs, 4 GB memory), a high volume of transaction logs can slow down the recovery speed.

    • Accelerated Database Recovery: RDS for SQL Server 2019 and later versions offer an Accelerated Database Recovery option, which may reduce the time required for this step. Evaluate whether to enable this option based on the official Microsoft documentation.

    Network switchover and connection migration

    Yes

    10 minutes

    None

    Example estimate

    Test instance: 4 vCPUs, 8 GB of memory, and 600 GB of data.

    • Create and configure new instance: Approx. 12 minutes.

    • Full backup (optional): Approx. 3 hours (600 GB / 200 GB per hour).

    • Restore full backup to target instance: Approx. 3 hours (600 GB / 200 GB per hour).

    • Incremental transaction log backup on source instance: Approx. 5 minutes ((10 GB / 200 GB per hour) + 2 minutes overhead).

    • Apply incremental transaction log backup on target instance: Approx. 5 minutes ((10 GB / 200 GB per hour) + 2 minutes overhead).

    • Database recovery: Approx. 2 minutes.

    • Network switchover and migration: Approx. 10 minutes.

    In this example, if a full backup has not been performed within the last 36 hours, the total estimated time is approximately 6 hours and 34 minutes. Otherwise, it is approximately 3 hours and 34 minutes.

    Upgrade recommendations

    • Maintenance window planning: Perform the upgrade during periods of low system load to minimize business impact.

    • Long-running transactions: Avoid long-running transactions, such as creating or rebuilding indexes and archiving data, during the upgrade process. This helps prevent extending the database recovery time.

    In a cross-time-zone scenario, how do I correctly set the switchover time for an instance upgrade?

    • Scenario: You are in the Dubai region, but your RDS for SQL Server instance is set to India Standard Time (IST). The instance is physically located in the Singapore region. In this complex cross-time-zone situation, you need to set the upgrade switchover time correctly to avoid business interruptions.

    • Goal: You plan to perform the upgrade switchover at 02:00 on May 11, 2024, IST (UTC+5:30).

    • Solution: Convert the instance's time (IST) to your browser's local time (Dubai time, GST). The instance's physical region is irrelevant in this scenario. If you plan the switchover for 02:00 on May 11, 2024, IST, you must log in to the RDS console and set the switchover time at your local Dubai time, which is 00:30 on May 11, 2024, GST (UTC+4).

    • Conversion method:

      1. Convert IST to UTC: 02:00 on May 11, 2024, IST (UTC+5:30) is 20:30 on May 10, 2024, UTC.

      2. Convert UTC to GST: 20:30 on May 10, 2024, UTC is 00:30 on May 11, 2024, GST (UTC+4).

    After an instance with CDC-enabled databases is upgraded, are existing CDC data and subsequent data capture affected?

    The instance upgrade retains existing CDC data and automatically restarts CDC jobs after the migration is complete. This ensures that newly generated data continues to be captured.

    Related API

    You can also upgrade the major database version by calling an API. For more information, see Modify an RDS instance.