I tried track changes on Amazon Redshift RG instances
This page has been translated by machine translation. View original
Introduction
Amazon Redshift RG instances are now available on the Trailing Track.
For an overview of RG instances and maintenance tracks (Current / Trailing), please refer to the following articles.
In this article, we created a cluster using the Trailing Track on RG instances and verified the behavior when switching to the Current Track. We also confirmed the behavior when changing in the reverse direction (Current → Trailing).
The version mapping at the time of testing (July 10, 2026) is as follows.
| Version | Patch | Track | Release Date |
|---|---|---|---|
| 1.0.331388 | Patch 201 | Trailing Track | 2026-06-16 |
| 1.0.343555 | Patch 202 | Current Track | 2026-06-29 |
| 1.0.347559 | Patch 203 | Current Track (latest) | 2026-07-06 |
Reference: Amazon Redshift patch versions
Verification Details
Test Environment
- Region: us-east-1
- Instance type: rg.xlarge × 2 nodes
- Operations: AWS CLI only
Creating a Cluster on the Trailing Track
aws redshift create-cluster \
--cluster-identifier rg-trailing-test \
--maintenance-track-name trailing \
--master-user-password '********' \
--master-username admin \
--node-type rg.xlarge \
--number-of-nodes 2
The cluster became available in approximately 2.5 minutes. We verified the initial state below.
| Item | Value |
|---|---|
| MaintenanceTrackName | trailing |
| ClusterRevisionNumber | 331388 (Patch 201) |
| NodeType | rg.xlarge |
| NumberOfNodes | 2 |
| Encrypted | true (AWS_OWNED_KMS_KEY) |
Changing from Trailing → Current Track
aws redshift modify-cluster \
--cluster-identifier rg-trailing-test \
--maintenance-track-name current
Immediately after execution, the cluster status remains available and the change is not applied instantly. The track change is recorded in PendingModifiedValues.
"PendingModifiedValues": {
"MaintenanceTrackName": "current"
}
The track change is applied during the maintenance window. There is no option equivalent to --apply-immediately for modify-cluster. In this test, we changed the maintenance window to a near-term time slot (UTC), and the application was triggered at the start of that window.
aws redshift modify-cluster \
--cluster-identifier rg-trailing-test \
--preferred-maintenance-window fri:14:33-fri:15:03
After the maintenance window started, the cluster transitioned to modifying and returned to available in approximately 5 minutes.
State after the change:
| Item | Before | After |
|---|---|---|
| MaintenanceTrackName | trailing | current |
| ClusterRevisionNumber | 331388 (Patch 201) | 343555 (Patch 202) |
| PendingModifiedValues | {MaintenanceTrackName: "current"} |
{} |
The change from Trailing → Current upgraded the cluster version from Patch 201 to Patch 202. Patch 202 was applied rather than Patch 203, and the version applied depends on timing and regional rollout status.
Attempting to Change from Current → Trailing Track
aws redshift modify-cluster \
--cluster-identifier rg-trailing-test \
--maintenance-track-name trailing
Result: No API error occurred, and the setting was accepted.
"PendingModifiedValues": {
"MaintenanceTrackName": "trailing"
}
At first glance it appears the change was reverted, but the result after the maintenance window was applied is as follows.
State after the maintenance window was applied:
| Item | Value |
|---|---|
| MaintenanceTrackName | current (unchanged) |
| ClusterRevisionNumber | 343555 (unchanged) |
| PendingModifiedValues | {MaintenanceTrackName: "trailing"} (remained) |
No version downgrade occurred. Although the request was accepted, no downgrade to Patch 201 took place, and PendingModifiedValues remained unresolved throughout the testing period.
This behavior is consistent with the official documentation, which states that no update occurs until a new Trailing Track release becomes available that is newer than the Current Track release.
Reference Information
The following is an excerpt of items from changes since Patch 198 that may impact operations.
| Change | Patch | Potential Impact |
|---|---|---|
| Expanded targets for automatic DISTKEY assignment | 203 | Tables with primary keys may now become eligible for automatic DISTKEY assignment even during COPY from Spectrum, with explicit column encoding, or COPY into non-empty tables |
| End of support for Python UDFs | 203 | According to the patch notes, changes related to Python UDF EOL are scheduled to be applied in phases from June 30, 2026. If Python UDFs are in use, it is necessary to verify whether migration to Lambda UDFs, SQL UDFs, or other alternatives is required |
| Change in MV auto-refresh execution classification | Current Track since Patch 198 | Auto-refresh is now executed at the same priority as user queries rather than as a background process, which may impact WLM capacity design |
| Change in automatic vacuum behavior | 203 | Reduces background automatic vacuum activity on clusters with a very large number of tables, improving stability for clusters that were experiencing excessive maintenance activity |
All of the above is based on official patch notes, and individual behaviors have not been measured independently. Please refer to the patch notes for details.
Summary
With RG instances now supporting the Trailing Track, it is possible to maintain a testing period on the Current Track while migrating to Current Track releases as needed. At the time of release, only the Current Track was supported, but with this update, RG instances have become easier to consider even in environments that rely on the Trailing Track.