Database change management—such as major and minor version upgrades or instance scaling—can be challenging to execute with minimal downtime and without disrupting business operations. Even with extensive testing, making direct changes to the production environment involves risk and can result in extended downtime.
To address these challenges, Amazon Relational Database Service (Amazon RDS) introduced Blue/Green Deployments for PostgreSQL in October 2023, primarily designed to simplify major version upgrades. This feature leverages community logical replication, which is well-suited for major version upgrades because it allows data replication between environments running different PostgreSQL versions. Unlike physical replication, which requires both the source and target to be on the same major version, logical replication supports replication across different PostgreSQL versions, making it essential for facilitating major version upgrades. However, community logical replication comes with certain limitations, such as the inability to replicate schema changes and a dependency on static parameter configurations, which can restrict its applicability in other scenarios.
With the recent addition of physical replication as an option for RDS Blue/Green Deployments, you can overcome most of the limitations of logical replication. This makes physical replication particularly well-suited for use cases like minor version upgrades, schema changes (DDL operations) in the blue environment, and storage adjustments.
When you create a blue/green deployment from an RDS for PostgreSQL DB instance, it uses physical replication by default. However, if you specify a major version upgrade when you create the blue/green deployment, it uses logical replication instead. For more information, refer to PostgreSQL replication methods for blue/green deployments in the Amazon RDS documentation.
In this post, we delve into the advantages of using physical replication in RDS for PostgreSQL blue/green deployments to simplify database operations and scale with application demands. We explore the key benefits of physical replication and provide a step-by-step guide to help you get started with this new capability.
Key benefits of physical replication in RDS for PostgreSQL blue/green deployments
Here’s a deeper look at how physical replication delivers enhanced flexibility, scalability, and performance for your databases.
Broad engine version support
Logical replication for blue/green deployments is limited to specific PostgreSQL engine versions, potentially excluding users running older or less commonly used versions. Physical replication for blue/green deployments, however, is supported across all PostgreSQL engine versions in RDS, making it accessible for every database. This universal compatibility ensures that no matter which engine version your application relies on, you can benefit from the enhanced capabilities of Blue/Green Deployments with physical replication.
Additionally, for customers on RDS Extended Support versions, blue/green deployments with physical replication provide a seamless way to apply critical security fixes while minimizing downtime.
To learn more about supported versions for each replication method, refer to PostgreSQL replication methods for blue/green deployments in the Amazon RDS documentation.
No dependency on static parameter configurations
Logical replication requires you to make manual updates to static database parameters before you can create a blue/green deployment. These changes necessitate a database restart, which introduces downtime even before you switch over the blue/green deployment.
Physical replication is enabled by default, which eliminates the need for manual updates or database restarts. This greatly simplifies the use of blue/green deployments. Physical replication avoids additional downtime, making it an ideal choice for database change management tasks that don’t involve major version upgrades.
Scalability for multi-tenant databasesÂ
In blue/green deployments that use logical replication, each logical database requires a dedicated replication slot. In multi-tenant environments, where thousands of logical databases are packed within a single RDS DB instance, the dense packing of databases significantly increases the number of required replication slots. This can lead to substantial replication lag and performance bottlenecks. Physical replication removes these limitations entirely, enabling seamless scaling for large multi-tenant environments.
Simplified storage adjustments in the green environment
Recent enhancements to blue/green deployments now allow you to decrease the allocated storage in the green environment. This feature is particularly valuable for lowering costs by optimizing resource usage. While not tied to a specific replication type, limitations like DDL restrictions in logical replication can complicate these changes. Physical replication eliminates such barriers, streamlining the process and reducing the risk of downtime or operational issues.
Modifying allocated storage, such as shrinking it to reduce costs, and performing major version upgrades are both significant changes to production environments. For effective risk management, it’s best to address these operations separately to ensure smoother transitions and maintain high availability.
No constraints on DDL operations
With logical replication, database administrators face restrictions on schema changes (DDL operations) during blue/green deployments due to limitations in community PostgreSQL. While you can make certain schema changes on the green environment with logical replication, these updates are often constrained and require careful planning to avoid inconsistencies. Any schema changes introduced on the green database can break logical replication and invalidate the blue/green deployment.
Physical replication eliminates these barriers by propagating schema changes made in the blue environment to the green environment. Although you can’t perform schema changes in the green environment due to its read-only nature, physical replication makes sure that changes made on the blue DB instance are seamlessly replicated.
Faster switchover with no sequence sync delays
Sequences are database objects that generate unique values, often used for auto-incrementing primary keys. With logical replication, blue/green deployments synchronize sequences between the blue and green environments to ensure consistency. This synchronization introduces delays in the switchover process, which increases downtime and complexity.
Physical replication eliminates the need for sequence synchronization, enabling faster and more predictable switchovers. For applications with high availability requirements, this improvement minimizes disruptions and keeps your services running smoothly.
Efficient handling of large objects
Large objects (LOBs) are data types used in databases to store large pieces of data, such as images, audio files, or documents. These objects are typically stored outside the regular table structure and are accessed using special database functions.
Managing large objects during blue/green deployments can be challenging with logical replication, because large objects created in the blue environment aren’t replicated to the green environment. As a best practice, we recommend that you avoid using large objects in PostgreSQL when possible due to their complexity and potential limitations. However, if your workload requires them, physical replication provides a reliable solution.
Physical replication provides seamless handling of large objects without extra configuration. This makes it a reliable choice for workloads that involve occasional use of large objects.
Getting started with physical replication in PostgreSQL blue/green deployments
Adopting physical replication for Amazon RDS for PostgreSQL blue/green deployments is straightforward. First, verify your use case. Physical replication is the default method for RDS for PostgreSQL blue/green deployments when you’re not performing a major version upgrade. Before you proceed, confirm that your deployment doesn’t require upgrading to a newer major PostgreSQL version. For more information, refer to PostgreSQL replication methods for blue/green deployments in the RDS documentation.
Then, follow the steps in Creating a blue/green deployment. For the Engine version for green databases setting, make sure to choose a PostgreSQL version that is the same major version as the source DB instance. If you’re using the AWS Command Line Interface (AWS CLI), make sure that the --target-engine-version parameter specifies a minor version upgrade or is excluded entirely if no upgrade is needed.
Upgrading from PostgreSQL versions that don’t support major version upgrades in blue/green deployments
Blue/green deployments for source PostgreSQL versions 15.3 and lower, 14.8 and lower, 13.11 and lower, 12.15 and lower, and 11.20 and lower use physical replication by default. Major version upgrades aren’t supported in blue/green deployments with these source versions.
If you want to perform a major version upgrade using a blue/green deployment and your source DB instance is on one of these PostgreSQL versions, perform the following steps:
- Create a blue/green deployment in which you perform a minor version upgrade to a target version that supports major version upgrades. This blue/green deployment will use physical replication.
- Enable logical replication in the green environment and reboot the green DB instance prior to switchover. This eliminates the need for additional downtime after switchover.
- Switch over the blue/green deployment.
- Create a new blue/green deployment with the new blue DB instance as the source, and perform a major version upgrade. This blue/green deployment will use logical replication.
Conclusion
In this post, we explored how physical replication enhances blue/green deployments for RDS PostgreSQL, overcoming the limitations of logical replication. By offering broader compatibility, eliminating constraints on DDL operations, simplifying large object handling, and enhancing scalability, physical replication provides a more efficient, flexible solution for PostgreSQL users. Whether you’re handling large databases, performing complex schema changes, or scaling your workloads, physical replication makes it simple to use RDS Blue/Green Deployments to minimize business disruptions.
Suggested next steps:
- Try it yourself – Follow the steps in the getting started section above to set up your own blue/green deployment that uses PostgreSQL physical replication.
- Explore further – Dive deeper into the AWS documentation to learn more about blue/green deployments and replication types for RDS for PostgreSQL: Using Amazon RDS Blue/Green Deployments for database updates
- Stay informed – Keep up to date with new features and improvements for RDS blue/green deployments through the AWS Database Blog.
About the authors
Liz Guillén is a Senior Technical Writer at AWS on the Amazon RDS documentation team. She specializes in creating clear, actionable content to help customers optimize their database operations.
Anisha Cherodian is a Senior Software Engineer at AWS on the RDS open source team, specializing in designing and implementing large-scale distributed systems. She has led major features like blue/green deployments for RDS PostgreSQL, and focuses on development, operational stability, and product innovation.
Source: Read More
