Deploying changes to a production database is one of the riskiest steps in the release pipeline. Schema changes or minor version upgrades, in particular, can lead to downtime, degraded performance, or even data loss if not handled carefully.

That’s why blue/green deployment is becoming a go-to strategy for teams that want safer, more controlled rollouts. With the SkySQL managed cloud database service, you can apply this pattern to your databases using tools already built into the platform.

In this blog post, we’ll walk through how SkySQL users can set up blue/green environments using the SkySQL portal, backup service, config manager, and replication, enabling you to make changes safely and confidently.

What Is a Blue/Green Deployment?

A blue/green deployment is a release strategy where two identical environments are maintained:

• Blue: your current live (production) database

• Green: a new database environment where changes are tested, validated, and eventually graduated as the new production database

Once the green environment is verified, you switch traffic from blue to green, typically with minimal downtime. If problems arise, you simply revert to the blue environment.

While this strategy is common in application deployments, implementing it at the database layer requires careful handling of state and data consistency. That’s where SkySQL’s built-in capabilities shine.

Why Blue/Green for Databases?

Using blue/green deployment on SkySQL gives you:

• No-risk schema changes

• A clean rollback path

• Testing on production data before being promoted to production

• Reduced downtime and safer cutovers

How to Set Up Blue/Green Deployment

1. Create a New "Green" Environment

In the SkySQL Portal:

• Create a new database service that matches the configuration of your existing (blue) environment, including topology, region, instance size, and storage type.

  • You can use this new environment for testing purposes or as a new production environment as part of your deployment strategy.

• Tag or name the environment, e.g., prod-green

You now have two independent environments: prod-blue (live) and prod-green (staging/testing).

2. Apply the Same Configuration Using SkySQL Configuration Manager

Once the green service is deployed, use the SkySQL Configuration Manager to:

• Duplicate the blue environment configuration to the green environment

  • Select the configuration currently used by the blue environment.

  • Click on “Duplicate” to duplicate the configuration and save it with a new name. 

This ensures both services have identical MariaDB settings, performance tuning, and plugin configurations.

Matching the configuration between environments is critical for accurate testing and safe cutovers.

3. Use SkySQL Backup Service to Replicate Data

Next, you’ll copy your current production data into the green environment:

• In the blue service, go to the Backup section and create a manual backup.

• Once completed, switch to the green environment and restore it from that backup.

This gives you a fresh, consistent copy of your production data in the green environment.

4. Set Up Replication from Blue to Green

To keep the green database in sync while you test, configure replication:

• Enable replication between the blue (primary) and green (replica) environments.

• Please follow the steps below to set up replication.

This ensures that any new changes in blue (e.g., writes from users) are reflected in green until the switchover.

Configure replication between the original database (blue-prod) and the new database (green) instance. This ensures that the green database stays up-to-date with real-time changes from the blue database. 

4.1. Allowlist Outbound IP: First, you need to add the outbound IP address of the green service to the allowlist of your blue service. This ensures the two databases can communicate securely. Outbound IP can be obtained from the “Service Details” page in the SkySQL portal.

Obtain the GTID position from which to start the replication by using the following stored procedure from the source (blue-prod) database. Please replace (service_id) with the service id of the replica.

Note down the “gtid_binlog_pos” value from the above output. gtid_binlog_pos = 0-1-7062,572700-572700-210. As an alternative you can find the “GTID POSITION” in the backup SkySQL Portal’s “Backups” screen. 

4.2. Configure GTID Position

Now, configure the green database by calling the stored procedure as below. Log in to the green-prod database service and run the following command from the mariadb command line.

Replace host and port with the source (blue-prod) hostname and port. Replace ‘gtid’ with the gtid_binlog_pos value obtained from the previous step.

1MariaDB [(none)]> CALL sky.change_external_primary_gtid(dbtwf12345678.syst0000.test1.skysql.com, 3306, 0-1-7062,572700-572700-210, true); 

When you run the above command, you’ll see an output similar to the following.

Copy the “GRANT” text (entire line) and run it in the blue database “blue-prod”.

Log in to the database service and run the following command:

1MariaDB [sky]> GRANT REPLICATION SLAVE ON *.* TO ‘skysql_replication_dbpgf28771827’@’%’ IDENTIFIED BY ‘Vs?wr^A86NNijlh4,-v57o?W&PGoQDa1’; Query OK, 0 rows affected (0.044 sec)

4.3. Start Replication: Once the GTID position is configured, start replication on the target database (“green-prod”) service.

1MariaDB [sky]>CALL sky.start_replication();

4.4. Verify Replication Status: Finally, verify that the replication is working correctly by checking the replication status on the standby service.

Example stored procedure to check replication status:

1MariaDB [sky]>CALL sky.replication_status();

5. Apply and Test Changes in the Green Environment

Once replication is running:

• Apply your schema changes, indexes, or performance improvements to the green environment.

• Run application integration tests or point your staging environment at green to validate behavior.

• Monitor performance and confirm compatibility.

6. Cut Over Traffic to the Green Environment

When you’re ready:

• Pause writes on blue to avoid split-brain or lost updates.

• Ensure green is caught up via replication.

• Point your application to the green environment by updating connection settings or DNS.

• Resume writes — now to green.

7. Roll Back if Needed (Optional)

If anything goes wrong:

• You can switch traffic back to blue (which is still intact)

• Investigate and address the issue in green before trying again

SkySQL Features That Make It Easy

SkySQL simplifies blue/green deployment with:

• Custom Deployments – Set up new environments with identical configs

• Backup & Restore – Create consistent, full-database snapshots

• Replication Support – Set up replication between SkySQL services

• Monitoring & Logs – Compare query performance before/after cutover

Best Practices

• Always test schema changes on a replica first (green)

• Automate schema migrations with tools like Liquibase or Flyway

• Use tags or clear service names to manage blue/green states

• Monitor replication lag before cutover

• Have a rollback plan (e.g., switch DNS, revert app config)

Conclusion

With SkySQL’s flexible deployment options, backup service, and replication support, implementing blue/green deployment is not only possible but also practical and powerful.

You gain control, visibility, and safety when making database changes, whether you’re applying complex schema updates or testing new performance optimizations.

• Start with your current production instance

• Create a green environment with a restored backup

• Sync them with replication

• Safely roll out your changes

Ready to give it a try? If you’re new to SkySQL, get started by creating a free serverless account at app.skysql.com. For existing customers, log in to SkySQL and set up your blue/green deployment today.