Pulumi Blog: Postgresql

AWS RDS - Blue/Green Deployments for Low-Downtime Updates

Elisabeth Lichtie — Mon, 23 Jun 2025 00:00:00 +0000

AWS RDS supports blue/green deployments to support database maintenance. In a blue/green deployment, you have one production (blue) and one staging (green) database. You can safely make changes to the green instance without affecting production and promote it to be the main instance. When you enable blue/green updates, Pulumi will temporarily set up a blue/green deployment for the duration of the update to minimize downtime.

There are many benefits to using blue/green deployments for updates, especially for critical databases that need to be kept available and safe from untested changes.

How it works

By default, updates to a database will be applied in-place, meaning there may be service interruptions while a database is modified especially when making long-running updates like changing the engine version, parameter groups, or storage settings.

blueGreenUpdate can be enabled for Low-Downtime Updates. When this setting is on and an update is performed, the program starts the update by creating a blue/green deployment to maintain availability. Then, it performs the requested update on the green instance, performs a guardrail check, promotes the green instance, and finally deletes the old instance and removes the blue/green deployment. This leaves just the updated database running with minimal downtime during the update while minimizing the downtime.

Though this strategy typically increases the amount of time that updates need to run, it minimizes downtime for the application by keeping a current version of the database available during the update process.

How to use

Please see the full example code here: Blue/Green Deployment Updates on RDS. To use blue/green deployments for your database updates, start by creating a database and corresponding parameter group.

const dbVersion = "14.18";

const parameterGroup = new aws.rds.ParameterGroup(
 "parameter-group",
 {
 family: `postgres${dbVersion.split(".")[0]}`,
 parameters: [
 {
 name: "rds.logical_replication",
 value: "1",
 applyMethod: "pending-reboot",
 },
 ],
 },
 { deleteBeforeReplace: false } // This explicitly calls out that the new group should be created before the old is deleted so that database availability can be maintained
);

const database = new aws.rds.Instance(
 "rds-instance",
 {
 allocatedStorage: storageAllocation,
 engine: "postgres",
 engineVersion: dbVersion,
 instanceClass: aws.rds.InstanceType.T3_Micro,
 username: dbUsername,
 password: dbPW,
 storageEncrypted: true,
 backupRetentionPeriod: 7,
 blueGreenUpdate: { enabled: true },
 skipFinalSnapshot: true,
 parameterGroupName: parameterGroup.name,
 },
 { dependsOn: [parameterGroup] } //This line can be omitted since the dependency is also inferred by the reference to parameterGroup.name
);

After running pulumi up with the above code, you’ll have a database deployed and attached to your custom parameter group. It’s important to create and attach a custom parameter group so that you can keep it up to date with any engine version upgrades. If you use the default parameter group, updates to the database version may fail when the green deployment is created since its parameter group family won’t match the new version. You can avoid a failure by ensuring that the parameter group’s family and engineVersion are always changed in the same update.

You won’t see the effects of having blueGreenUpdate enabled until you run your first update. Change any part of the database configuration and run pulumi up again to start the update. In the example above, you can change dbVersion to 15.13 to trigger an update to both the parameter group and the instance.

Once the update kicks off, you can watch on AWS as the blue/green deployment is created and the original settings are copied to the green instance.

Then, the green instance will be updated with the new settings and the program will switch over to the green instance and clean up.

After that, your update has been completed with minimal disruption!

Additional Considerations

General limitations and considerations for Amazon RDS blue/green deployments are listed in the AWS documentation, but there are a few other considerations that should be taken into account when using them for updates with infrastructure as code (IaC).

No Custom Checks: Because IaC will automatically perform the switchover when the update is complete, you will not have the opportunity to perform custom checks on the green instance before promoting it. RDS will run some basic guardrails checks before performing the switchover, but you will not be able to perform any additional checks.
No Cluster Support: This feature only works with database instances, not with clusters or instances that are in a cluster.
Long Update Times: Because the IaC program will deploy temporary resources before performing the update and destroy them after, blue/green updates will take considerably longer than their in-place counterparts.
Manual Cleanup: Because the green instance and blue/green deployment are temporary resources designed to decrease downtime during the update, they are not tracked in the IaC state. If the update fails partway through, these temporary resources may have to be cleaned up manually. If the update is interrupted, you can delete the blue/green deployment and green database to get back into a manageable state.
Resource ID Change: On an update, the resource ID of the database might change since a new instance has been created. The endpoint and other details about the database will be maintained by AWS during switchover, but the resource ID should be dynamically retrieved from the stack outputs whenever it is used to ensure it stays up to date. Usually, no application or connection details will need to be updated since they don’t rely on the resource ID itself.
Types Of Updates: The blue/green update strategy will be used for changes that require a maintenance window including updates to the engine version, parameter group, storage and performance settings, and optimized writes.

Adding PostgreSQL State Backend Support to Pulumi: A Community Contribution Journey

Matan Baruch — Thu, 19 Jun 2025 14:46:07 +0300

When managing infrastructure as code at scale, reliable state storage is essential. Pulumi Cloud provides a fully managed, secure, and scalable solution out of the box. For teams that choose to build and maintain their own backend, Pulumi now offers support for PostgreSQL as a DIY state storage option—though this requires additional operational overhead and careful consideration around performance, security, and maintenance.

The Need for Database-Backed State Storage

Traditional DIY backends in Pulumi have relied on object storage systems like AWS S3, Google Cloud Storage, or Azure Blob Storage. While these work well for many use cases, they have limitations when it comes to handling very large state files, complex locking mechanisms, and transactional guarantees that some enterprise environments require.

PostgreSQL stood out as an excellent candidate for state storage due to its:

Large object support: Ability to handle substantial state files without size constraints
ACID compliance: Robust transactional guarantees for state consistency
Mature ecosystem: Well-established tooling and operational practices
Scalability options: From single instances to complex replication setups
Security features: Comprehensive authentication and authorization capabilities

The Community Contribution Process

This feature came to life through PR #19581, which addressed a long-standing community request tracked in issue #5632. The development process showcased the collaborative nature of open-source development, with multiple rounds of feedback, testing, and refinement.

Key Technical Challenges

The implementation required several technical considerations:

1. Integration with Go Cloud Development Kit (CDK)

The PostgreSQL backend needed to integrate seamlessly with Pulumi’s existing blob storage abstraction layer. This was achieved by implementing the blob.BucketURLOpener interface:

// URLHandler is a URL opener for PostgreSQL URLs.
type URLHandler struct{}

// OpenBucketURL implements blob.BucketURLOpener.
func (p URLHandler) OpenBucketURL(ctx context.Context, u *url.URL) (*blob.Bucket, error) {
 pg, err := NewPostgresBucket(ctx, u)
 if err != nil {
 return nil, err
 }
 return pg.Bucket(), nil
}

2. Database Schema Design

The implementation uses a simple but effective schema for storing state data:

CREATE TABLE IF NOT EXISTS pulumi_state (
 key TEXT PRIMARY KEY,
 data JSONB NOT NULL,
 created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
 updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

This design allows for efficient key-based lookups while leveraging PostgreSQL’s native JSON support for flexible state data storage.

3. Cross-Platform Testing

One of the significant challenges was ensuring the implementation worked across different operating systems and CI environments. The solution involved using testcontainers-go to spin up PostgreSQL instances during testing, with appropriate skip conditions for environments where Docker isn’t available:

func skipIfDockerNotAvailable(t *testing.T) {
 if runtime.GOOS == "windows" || runtime.GOOS == "darwin" {
 t.Skip("Skipping test: Docker not available on this platform in CI")
 }

 // Additional Docker availability checks...
}

Performance and Limitations

PostgreSQL wins over a plain S3 bucket

ACID transactions with row-level locking – A postgres backend means strong consistency guarantees.
Faster for smaller state files – Community benchmarks show improvements on S3 backend speed for smaller state files.
Point-in-time restore – WAL-based backups allow for easier rollback.
Deep observability – plug pg-metrics into Grafana/APM for real-time insight.

Gaps you’ll still close only with Pulumi Cloud

Server-side policy guardrails (CrossGuard) – automatically enforced policies on every preview or deploy.
Always-on drift detection – automatic scans catch out-of-band changes.
Managed Deployments – fully managed runners, PR previews, and dependent stack updates.
Org-wide RBAC, SSO/SAML, immutable audit logs – turnkey for teams and auditors.
Search & analytics across all cloud resources (Insights) – not just those managed by Pulumi.
Enterprise Secrets & Configuration (ESC) - encrypted secrets and config with RBAC, versioning and audit trail.
SOC 2, high availability, and painless upgrades – Pulumi operates the control plane so you don’t have to.

Getting Started

Using the PostgreSQL backend is straightforward:

Login to your PostgreSQL backend:

pulumi login postgres://pulumi_user:secure_password@localhost:5432/pulumi_state?sslmode=require

Use Pulumi normally:

pulumi up
# Your state is now stored in PostgreSQL!

Community Impact

This contribution demonstrates the power of community-driven development in open source projects. It addresses a real need expressed by Pulumi users while maintaining the high quality standards expected from the project.

The implementation follows Pulumi’s architectural patterns and coding standards, making it a seamless addition to the existing codebase. The comprehensive documentation and testing ensure that future maintainers can easily understand and modify the code.

What’s Next?

The PostgreSQL backend opens up several possibilities for future enhancements:

High Availability: Support for PostgreSQL clustering and replication
Performance Optimizations: Caching strategies and connection pooling
Advanced Features: Custom backup strategies and state analytics
Multi-tenant Support: Isolation patterns for multiple teams or environments

Conclusion

The addition of PostgreSQL state backend support to Pulumi represents more than just a new feature—it’s a testament to the collaborative nature of open source development and the power of community contributions. By providing enterprise-grade state storage options while maintaining the simplicity that makes Pulumi great, this feature enables organizations to adopt infrastructure as code with confidence.

Whether you’re running a small startup or managing infrastructure for a large enterprise, having robust, reliable state storage options is crucial. The PostgreSQL backend provides an improved approach to Do-It-Yourself state management.

If you’re interested in contributing to Pulumi or have ideas for new features, the community welcomes your contributions. This PR serves as an excellent example of how community members can make meaningful improvements to the project while learning from experienced maintainers and following established best practices.

Using AWS Quick Starts with the Pulumi Registry

Aidan Hoolachan — Wed, 05 Jan 2022 00:00:00 +0000

As somebody who works on AWS projects across numerous projects, teams, and industries; I see the following three common types of infrastructure problems. I think the Pulumi Registry provides an incredible solution to each of these problems and will fundamentally change how people interact with AWS.

Common AWS infrastructure problems:

AWS Console Wizard Fever - These companies use the AWS Console to deploy resources. They move very quickly initially but eventually their AWS accounts become cluttered with untracked resources and they need to do some heavy lifting to set up robust dev / staging / prod environments. Many AWS developers scoff at the idea of using the Console, but I actually think this is currently an okay approach for a lot of people / companies in the early stages of AWS development. The console provides a lot of assistance when doing deployments and most people don’t need very complicated infrastructure initially. It’s not ideal because of the tech debt but it’s the right choice for many situations (at least, it was the right choice before the Pulumi registry).
YAML/JSON CloudFormation Template Ceiling - These companies have the right idea to use Infrastructure as Code, but CloudFormation YAML/JSON templates or other limited frameworks like Amplify are unwieldy and have their own scaling problems. Most people who work closely with AWS advocate for Infrastructure as Code (I do too), but it really is a steep learning curve and can be a lot of overhead for many simple applications. Setting up email alarms when a database goes down requires specialized AWS knowledge to do correctly – which makes a basic feature like email/slack alarm notifications feel like a sophisticated luxury. It shouldn’t be complicated, but it is.
AWS Lock-in - These are companies who lean into the AWS ecosystem for convenience sake. They might choose Cognito over a third-party Identity Provider even though the third-party Identity Provider might be a superior service.

The underlying cause of these problems is that AWS’s core services are designed for modularity within the AWS ecosystem, which is great for flexibility and experienced AWS developers, but it makes building best-practice AWS environments surprisingly difficult. Most “best practice” features on AWS, like email alarms when a database goes down, should really be the standard practice, but those features currently require complicated cross-service relationships that are difficult to implement correctly. The AWS ecosystem has been waiting for a layer of abstraction on top of these resources.

Pulumi and the AWS Quick Starts in the Pulumi Registry use higher-order components to abstract away that underlying complexity which makes configuring, deploying, and managing critical AWS resources straightforward – like it should be.

Configuring an Aurora Postgresql database with best practices (again, what should really just be the standard practices) requires specialized AWS knowledge and provisioning a zoo of other critical resources:

Encryption (2 resources) - KMS Key + KMS Key Policy
Access logging (4 resources) - S3 + S3 Bucket Policy + Encryption (KMS, again) + IAM Role
Alarms with notifications (3 Resources) - Cloudwatch Events + SNS + SNS Subscription
Networking infrastructure - (4+ resources) VPCs + Subnets + Gateways, etc.
Username and password - (1 resource) Secrets Manager Secret
Redundancy - (multiple resources) RDS multi-AZ clusters
IAM - (too many resources) Various IAM roles and policies

If “Aurora Postgres RDS” were a third-party SaaS or PaaS service provider, the service would abstract away the above details and provide simple parameters for enabling encryption, alarms, notifications, network security, redundancy, monitoring, and logging. With Pulumi, that abstraction is possible while providing open-source access to the underlying AWS resource definitions and with much more flexibility than traditional CloudFormation or Terraform. Those features can even be enabled by default. I believe that AWS “best practices” will also become the easiest approach with Pulumi as the ecosystem matures around the best packages.

When writing the Pulumi providers for AWS Quick Start VPC, AWS Quick Start Aurora Postgres, and AWS Quick Start Redshift, we were able to fight through the complexity and implement the best practices listed above. Those practices are enabled by default but can be disabled using a flag (eg enableEncryption: false). The result is a simple interface for deploying a VPC, an Aurora Postgresql cluster, and a Redshift cluster along with all of the other resources needed for best practice deployments. The process for writing these AWS providers was straightforward and intuitive. The Pulumi deployment and debug process was pleasant and I was able to go through most of the deploy + debug + tear down lifecycle without leaving the terminal.

The following code deploys a VPC, an Aurora Postgresql Cluster, a Redshift Cluster, and the various helper resources needed for encryption, logging, database alarms, vpc flow logs, etc. – for a total of 47 resources deployed using only three functions with simple parameters.

import * as pulumi from "@pulumi/pulumi";
import * as vpcQuickstart from "@pulumi/aws-quickstart-vpc";
import * as redshiftQuickstart from "@pulumi/aws-quickstart-redshift";
import * as auroraQuickstart from "@pulumi/aws-quickstart-aurora-postgres";

const notificationEmail = process.env.notificationEmail;
const dbPasswordSecret = pulumi.secret(process.env.databasePassword);

// Create a best-practices VPC
// Deploys 21 resources
const multiAvailabilityZoneVpc = new vpcQuickstart.Vpc("example-aurora-vpc", {
 cidrBlock: "10.0.0.0/16",
 availabilityZoneConfig: [{
 availabilityZone: "us-east-1a",
 publicSubnetCidr: "10.0.128.0/20",
 privateSubnetACidr: "10.0.32.0/19",
 }, {
 availabilityZone: "us-east-1b",
 privateSubnetACidr: "10.0.64.0/19",
 }]
})

// Create a best-practices Aurora Postgresql cluster
// Deploys 17 resources
const multiAvaialabilityZoneAuroraCluster = new auroraQuickstart.Cluster("example-aurora-cluster", {
 vpcID: multiAvailabilityZoneVpc.vpcID,
 dbName: "myDemoDatabase",
 dbEngineVersion: "11.9",
 dbInstanceClass: "db.t3.medium",
 availabilityZoneNames: ["us-east-1a", "us-east-1b"],
 dbNumDbClusterInstances: 2,
 dbMasterUsername: "mainuser",
 snsNotificationEmail: databaseNotificationEmail,
 enableEventSubscription: true,
 dbMasterPassword: dbPasswordSecret,
 dbParameterGroupFamily: "aurora-postgresql11",
 privateSubnetID1: multiAvailabilityZoneVpc.privateSubnetIDs.apply(x => x![0]),
 privateSubnetID2: multiAvailabilityZoneVpc.privateSubnetIDs.apply(x => x![1]),
});

// Create a best-practices Redshift cluster
// Deploys 8 resources
const cluster = new redshiftQuickstart.Cluster("example-redshift-cluster", {
 vpcID: multiAvailabilityZoneVpc.vpcID,
 dbPort: 5432,
 dbClusterIdentifier: "example-redshift-cluster",
 dbMasterUsername: "mainuser",
 notificationEmail: notificationEmail,
 enableEventSubscription: true,
 dbMasterPassword: dbPasswordSecret,
 dbName: "main",
 dbNodeType: "dc2.large",
 subnetIDs: multiAvailabilityZoneVpc.privateSubnetIDs as pulumi.Output<string[]>
})

These AWS Quick Start components are recommended for developers with all levels of AWS skill. For developers who don’t work with AWS frequently, these Quick Starts can replace the AWS Console Wizards for confidently provisioning resources.

For experienced AWS developers who want to use these components and are concerned about abstraction, there are several options: (1) review the underlying open source code, (2) do a quick proof-of-concept deployment and use Pulumi’s resource management tools to review the resources, and (3) when necessary, alter the underlying code! In my experience, because I was so accustomed to defining every painful detail of AWS infrastructure, the abstractions felt almost too easy to use. However, once I became comfortable with the underlying design patterns, these packages made deploying complicated AWS architectures incredibly easy, quick, and reliable.

For service providers considering providing a Pulumi package for their service offering – as an AWS developer, the most exciting part of this toolset is the ability to choose non-AWS tools without sacrificing convenience. I sometimes choose Cognito over Okta simply because Cognito is in the AWS ecosystem. If service provider packages are as convenient as using native AWS tools, they become more competitive with AWS’ native services.

Returning to the initial three problems:

AWS Console Wizard Fever - By creating many of the “helper” resources (like email notifications when the database goes down), the Pulumi registry serves the same purpose as the AWS Console wizards – “best practice” infrastructure / applications are available at the click of a button.
YAML/JSON CloudFormation Template Ceiling - Software / programming languages are much easier to work with than YAML or JSON templates. Programming languages provide simpler logic, abstraction, auto-complete, guardrails, open-source imports, and all of the other benefits of programming languages. Furthermore, the Pulumi framework provides infrastructure review tools during deployments, which mitigates the risks of programming language bugs affecting deployments (eg. there are robust safeguards against an infinite “for” loop spinning up an infinite number of EC2 instances).
AWS Lock-in - In addition to Pulumi making it substantially easier to use AWS services, Pulumi makes it substantially easier to use other SAAS and cloud providers alongside AWS resources. As the registry matures around standard abstractions, I can imagine constructs for “Postgres Database” or “Serverless Website” or “Next.js Deployment” that are implemented by multiple SAAS or cloud providers such that a developer can switch clouds with a few minor configuration changes.

For getting started, I recommend starting with the examples for the AWS Quick Start VPC, AWS Quick Start Aurora Postgres, and Aurora Quick Start Redshift.