Cloud Database Repatriation: Moving RDS, Aurora, Azure and Cloud SQL Back to Self-Managed Open Source

The short answer

Repatriating a managed database means two projects: a data move and an operating model. The data move is the easier part. RDS, Aurora, Azure Database for PostgreSQL and Cloud SQL all support logical replication or binlog replication to a server you run, so a large database can be copied while it stays live and cut over in minutes. The harder part is everything the service did for you: backups, failover, patching, monitoring and the 3am call. Plan that first, and repatriate only where you can staff it or contract it.

The cloud is still the better home for many workloads. Repatriation makes sense when a specific cost, constraint or calendar problem outweighs the operations work you take back.

When repatriation makes sense, and when it does not

The calendar point is often the trigger. RDS for MySQL 8.0 moved to paid Extended Support on 1 August 2026 and Azure Database for MySQL follows on 1 February 2027. For PostgreSQL, RDS Extended Support for PostgreSQL shows how the charge works. A forced upgrade or a new line item is a reasonable moment to ask where the database should live.

Egress: what moving the data costs

Data transfer out of a cloud is billed, and a large database plus a replication stream can add up. AWS runs a programme for customers leaving: contact AWS Support, and it can credit data transfer out to the internet for the move. Since an update on 30 September 2025, approved customers have 90 days to complete the move, and AWS does not require you to close your account. Check whether your other providers offer something similar before you start, and size the replication period so it fits inside the window.

Migration methods by source

PostgreSQL out of RDS: the outline

-- On RDS, after setting rds.logical_replication = 1 and rebooting
CREATE PUBLICATION repatriate FOR ALL TABLES;

-- On your server, after restoring the schema with pg_dump --schema-only
CREATE SUBSCRIPTION repatriate
  CONNECTION 'host=mydb.xxxx.rds.amazonaws.com dbname=app user=repl password=...'
  PUBLICATION repatriate;

Logical replication copies table data, not schema changes or sequence values, so freeze DDL during the move and set sequences on the target at cutover. Check that every table has a primary key or another replica identity before you publish it: without one, updates and deletes on that table fail on the source.

MySQL out of RDS: the outline

AWS documents the route: create a replication user, set binlog retention long enough with mysql.rds_set_configuration, create an RDS read replica and pause it with mysql.rds_stop_replication so binlogs are kept, take a mysqldump --single-transaction --routines --triggers from it, load the dump on your server, then start replication from the recorded binlog position. Because the external server must run the same version or later, an RDS 8.0 source can replicate to a self-managed 8.4 server, which lets you combine the move with the upgrade if you have tested the application on 8.4.

The operating model you need afterwards

A managed service bundled these jobs. Each one needs an owner on day one after cutover:

• Backups and point-in-time recovery, with restores tested on a schedule, not assumed. PostgreSQL backup, recovery and high availability covers the PostgreSQL side.
• High availability: Patroni or repmgr for PostgreSQL, replication or Group Replication for MySQL, with failover rehearsed.
• Patching: minor releases every quarter, and a plan for when a major version reaches end of life.
• Monitoring and on-call: replication lag, disk, connections, vacuum or purge, and someone who answers the page.
• Security: TLS, authentication, network policy, encryption at rest and audit logging that the service previously configured.
• Capacity: hardware or VM sizing and storage growth, reviewed regularly.

Write the runbooks before cutover and rehearse a failover and a restore on the new platform. If the team cannot take on all of this, a support or operations contract should start on the day you cut over, not after the first incident.

A cutover sequence

1. Build the target cluster with HA, backups and monitoring in place.
2. Restore the schema, start replication and let it catch up.
3. Validate row counts and checksums on the largest tables, and run read traffic against the target.
4. Freeze writes, wait for replication to drain, set sequences, and switch application connection strings.
5. Keep the cloud instance read-only for an agreed period as a fallback, then decommission it and stop the replication slot.

Where OSSeva fits

OSSeva supports the self-managed PostgreSQL, MySQL, MariaDB, Redis, Valkey and RabbitMQ you land on, on bare metal, VMs, any Kubernetes or any cloud account, under one contract and one escalation path, priced per cluster. OSSeva Assure covers migration planning, and OSSeva Operate runs the operating model for you: 24/7 replication and failover monitoring, point-in-time recovery testing, a 15-minute P1 response, and Critical CVEs (CVSS 9.0 and above) patched within 48 hours and High within 7 days. If the version you move to later reaches end of life, OSSeva patched builds keep it covered while you plan the upgrade, as they do today for PostgreSQL 11 to 14 and MySQL 5.7 and 8.0. Cloud database repatriation describes the offer; book a discovery call for a quote.

Frequently asked questions

What is cloud database repatriation?

Moving a database from a managed cloud service such as Amazon RDS, Aurora, Azure Database or Cloud SQL back to infrastructure you run: your own data centre, colocation, VMs or a Kubernetes cluster, often still in a cloud account.

How do you migrate from RDS to self-managed PostgreSQL?

Turn on logical replication with the rds.logical_replication parameter, restore the schema on your server, create a publication on RDS and a subscription on the target, let it catch up, then cut over. pg_dump and pg_restore work for databases that can take a longer outage.

Can you replicate out of Aurora?

Yes. Aurora PostgreSQL supports logical replication once rds.logical_replication is set in a custom cluster parameter group, and Aurora MySQL supports binlog replication to MySQL outside RDS, except on Aurora Serverless v1.

Does AWS charge egress when you leave?

Data transfer out is normally billed, but AWS will credit it for customers moving off AWS who request it through AWS Support. Approved customers have 90 days to complete the move.

When is staying in the cloud the better choice?

When load is spiky, when the application lives in the same cloud, when the managed service's features and calendar suit you, or when nobody can own backups, failover and patching. Repatriation trades a bill for responsibility.

Is self-managed open source cheaper than RDS?

Sometimes. Steady workloads on owned or reserved capacity often cost less, but the comparison has to include the people and contracts that replace what the service did. Use your own figures; the support cost calculator covers the support side.