How I used RDS Blue Green deployment to upgrade my company database

In this post I would like to write about a task I have done over the last few months. My team needed to upgrade our RDS MySQL instance from 8.0 to 8.4, since AWS support for version 8.0 will end in 06/2026, leading to higher costs in AWS to maintain the old version. With that in mind, we decided to do the upgrade.

Currently, I am working at a streaming company, and my team is responsible for the catalog of the service. Our database is a critical point in the company, so with that in mind we thought of a solution that could give us safety and a short downtime.

To avoid any problem, the solution was to use a Blue/Green deployment strategy from RDS.

In a nutshell, B/G deployments create two environments. One environment has the current version of your database this is the blue one. Then it creates a green environment, which has the new version of your database. After you set everything up, you can just switch over between the two.

Quick lab

Let's create a Terraform project with a database in it:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}
provider "aws" {
  region = "us-east-1"
}
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "6.6.0"
  name                 = "database_test"
  cidr                 = "10.0.0.0/16"
  azs                  = ["us-east-1a", "us-east-1b"]
  public_subnets       = ["10.0.4.0/24", "10.0.5.0/24", "10.0.6.0/24"]
  enable_dns_hostnames = true
  enable_dns_support   = true
}
resource "aws_db_subnet_group" "this" {
  name       = "database_test"
  subnet_ids = module.vpc.public_subnets
}
resource "aws_db_parameter_group" "this" {
  name = "test"
  family = "mysql8.0"
}
resource "aws_db_instance" "this" {
  allocated_storage    = 5
  db_name              = "mydb"
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"
  username             = "master"
  password             = var.db_password
  parameter_group_name = aws_db_parameter_group.this.name
  db_subnet_group_name = aws_db_subnet_group.this.name
  skip_final_snapshot  = true
  publicly_accessible    = false
}

After the creation, just click on Actions and then create the deployment following the UI.

After having the two environments, you are able to modify the green instance as much as you want. Some ideas of things you can do with no impact: changing parameter values, changing the instance of the database, and also doing DML changes.

However, for DML changes, please take care not to introduce breaking changes analyze carefully before doing it. For example, you cannot remove a column from the green database while it still exists in the blue one, and you should not change the structure in a way that can corrupt data, such as changing an int field to a string field. Also, if you want to do it, you need to change a parameter group on the green database to set read_only to false, since the green one is usually just for reading.

On the day of the maintenance, I just needed to click a button and the database version was changed. The downtime was minimal less than 1 minute and no breaking changes or regressions were introduced between the two versions. Actually, going from version 8.0 to 8.4, we got a boost in speed.

It was a nice experience, and I would like to say that this feature from AWS works very well. If you need to do such changes in your database, you should consider it.