From RDS to EC2: migrating a 500 GB MariaDB database with 10 minutes of downtime

luroConnect, a managed hosting platform for Magento (Adobe Commerce), has published a detailed account on the official MariaDB blog of migrating a production database of over 500 GB from Amazon RDS to self-managed MariaDB on EC2. The author is Pradip Shah, and the piece was picked up by the MariaDB team because it describes, step by step, the preparation, cutover and rollback plan, complete with real billing figures.

The case concerns a Magento store handling roughly a thousand orders a day. According to the AWS invoices cited in the article, in June 2025 (a "steady-state" month) the monthly spend for the database alone on RDS was $13,313: a db.r6i.12xlarge master instance in Multi-AZ, a db.r6i.4xlarge read replica, and $3,515 in io2/gp3 storage. In July the figure rose to $13,581. In August, during the period when both stacks were running side by side, RDS cost $9,269 while the new database server on EC2 cost $3,377, in that same month.

How the migration was carried out

The replication setup was built using mydumper/myloader for the initial dump and MariaDB GTID-based replication throughout the chain. The new EC2 server was first attached as a replica of RDS, then itself became the source for a second EC2 replica, while a new RDS instance was configured as a replica of the EC2 server, for rollback purposes.

The actual cutover, according to the article, took less than 10 minutes: promoting the EC2 replica, switching the ProxySQL backend from RDS to EC2, testing, and exiting maintenance mode. No changes were needed on the Magento application side, since connections go through ProxySQL rather than directly to the database.

The rollback plan

The account describes two layers of safety: a quick switch via ProxySQL in the minutes following cutover, and an RDS instance kept in sync as a replica of the EC2 server for weeks, ready to be promoted should performance issues emerge only under prolonged real-world load.

An incident that occurred during the RDS period, a stuck replication thread on a read replica that caused binlogs to pile up until they saturated the volume shared with the data, bringing down the master, was the motivation behind the EC2 design decision to separate the binlog volume from the data volume.

The original article is on the luroConnect blog, republished on mariadb.org at the address given in the source.