// Cloud database repatriation
Bring managed databases back under your control.
Self-managed PostgreSQL, MySQL and Valkey, supported from day one. When it makes sense.
Managed databases are convenient, and for many teams they are the right answer. For some, version calendars, extension limits, data residency or the way the bill grows make running the database themselves worth it again. OSSeva moves workloads from Amazon RDS, Aurora, Azure Database and Cloud SQL to PostgreSQL, MySQL or Valkey on infrastructure you control, and supports it from cutover. We will also tell you when staying put is the better choice.
Trusted globally by enterprises
When repatriation makes sense
These are the reasons we hear most. If none of them apply to you, a managed service is probably still the right place for your database.
The version calendar is not yours
Managed services set when a version leaves standard support and when paid extended support starts. On a self-managed cluster with patched builds, the upgrade happens when your team is ready.
You need what the service will not run
Extensions, plugins, superuser access, specific builds or configuration settings that the managed service does not allow.
Where the data lives, and what it costs, matter
Data residency rules, a move to your own hardware or another cloud, or a bill that grows with every instance size. The calculator compares your own numbers.
What OSSeva delivers
Assess honestly
A review of each database, why you want to move it, and what it would cost to run yourself. If staying is better, the report says so.
Design the target
PostgreSQL with Patroni, MySQL with replication, or Valkey, on bare metal, VMs, any Kubernetes or another cloud account, sized from your current metrics.
Replicate out
Online replication from the managed service where the engine allows it, such as PostgreSQL logical replication, which RDS for PostgreSQL enables with the rds.logical_replication parameter. Otherwise a rehearsed dump and restore.
Cut over
A runbook with a final sync, go and no-go checks and a rollback to the managed service.
Run and patch
Signed builds, including for versions past community end of life, with migration planning and audit evidence on OSSeva Assure.
Operate around the clock
On OSSeva Operate, 24/7 monitoring, a 15-minute P1 response and Critical CVEs (CVSS ≥ 9.0) patched within 48 hours and High within 7 days.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Stay on the managed service | No migration, and operations included in the bill | The provider's version calendar, extension list and extended support charges. For most small and steady workloads this is the right answer. |
| Pay for the provider's extended support | More time on an old version inside the service | Charges on top of the instance, and a fixed end date. |
| Self-manage without support | Full control | Your team owns every patch, failover and incident. |
| OSSeva repatriation and support | Self-managed PostgreSQL, MySQL or Valkey, migrated and then supported | You own the infrastructure, or add OSSeva Operate to run it. |
Logical replication setup from the Amazon RDS for PostgreSQL user guide, checked on 7 October 2026. OSSeva coverage from the OSSeva PostgreSQL and Redis technology pages and the MySQL technology page. Costs depend on your own estate; the calculator uses your inputs.
Frequently asked questions
What is cloud database repatriation?
Moving a database from a cloud provider's managed service back to infrastructure you run yourself, whether that is your own data centre, VMs or Kubernetes in a cloud account you control.
How do we move from RDS to self-managed PostgreSQL?
Usually with PostgreSQL logical replication. You set rds.logical_replication to 1 on the RDS instance, publish the tables, subscribe from the new cluster, let it catch up, and then switch the application over in a short window. Large or unusual schemas get a rehearsal first.
When should we not repatriate?
When the database is small or steady, your team has no appetite to run infrastructure, or the only goal is to avoid a short extended support charge. Moving a healthy database just for that is rarely worth it.
Can you move Aurora, Azure Database or Cloud SQL workloads?
Yes. The approach is the same: replicate where the engine allows it, rehearse, cut over and support. The setup steps differ by provider, and we check them for your service during the assessment.
What about ElastiCache?
Redis workloads on ElastiCache can move to self-managed Valkey or BSD-licensed Redis, both supported by OSSeva.
Who is this for?
Teams with a concrete reason to leave a managed database, such as version control, extensions, residency or cost, and the willingness to own infrastructure or have OSSeva operate it.
Find out if repatriation is right for your databases.
Book a discovery call. If staying on the managed service is better, we will say so.