Neon is a serverless Postgres database designed to help teams ship reliable and scalable applications faster, with features like compute autoscaling, database branching, scale-to-zero, and instant PITR. Teams migrate to Neon from RDS or Aurora Serverless for several reasons, the most common being:

• From RDS, they are looking for a more agile database with a modern developer experience that allows them to build and ship faster while reducing costs for their development and testing workflows.
• From Aurora Serverless, they want to maintain the serverless experience but with the added benefits of scale-to-zero, greater transparency, and lower overall costs.

Since Neon is based on Postgres, migrating workloads from RDS or Aurora to Neon is relatively straightforward. We recently published a set of migration guides based on logical replication, which can really help you in your migration process—especially if you’re moving a production workload and need to switch without downtime. In this blog post, we’ll walk you through these guides and the migration strategies you can follow.

Migration strategies from RDS/Aurora to Neon

When migrating a database from Aurora or RDS to Neon with minimal downtime, the right strategy will mostly depend on the size of your database and your tolerance for downtime.

Strategy 1: Small database, tolerable downtime

Dumping and restoring a dataset takes time, especially for larger databases. This method also requires some downtime because any data changes that occur during the dump/restore process won’t be captured—you will be restoring your database to the point in time when you initiated the dump. However, if your dataset is small enough and you can tolerate a few hours of downtime, the inconvenience may be worth it, as a dump/restore is by far the simplest migration path.

This method is outlined in detail in this guide. The general steps look like this: 

1. Create a new database in Neon that will receive the data, mirroring the schema of the source database. Ensure all necessary configurations and extensions are set up.
2. Use pg_dump to create a dump of your Aurora/RDS database. This process might take some time.
3. Once the dump is complete, transfer the dump file to a machine that can access your Neon database. Then, use pg_restore to restore the dump into your Neon database.
4. After confirming that all data has been restored and the application is functioning correctly, update your application to point to the new Neon database.

Strategy 2: Large database, minimal downtime

For larger databases, or if you cannot afford significant downtime, logical replication is the recommended approach. Logical replication is a method of copying data from one Postgres database to another in real time. This approach is particularly useful for migrations because it enables you to keep your original database fully operational while the data is being copied to the new environment, something that is not possible with plain dump/restore. 

With logical replication, data changes made to the source database (i.e. inserts, updates, deletes) are continuously streamed to the target database. This means you can perform the bulk of the data migration in the background without interrupting your production workload.

Once the initial data synchronization is complete and the source and target databases are in sync, you can switch your application to the new Neon database with minimal downtime—typically just a brief period to apply the final changes and update your connection strings.

We have published detailed logical replication guides in the Neon docs:

• Replicate data from Amazon RDS Postgres to Neon 
• Replicate data from Amazon Aurora Postgres to Neon 

All the steps you need to follow to carry out your migration are in those guides. The general steps are as follows:

1. Prepare the target Neon database as the replication target.
2. Enable logical replication in your Aurora/RDS instance by setting the necessary parameters and creating a publication on your source database for the tables you want to replicate. Detailed instructions are provided in the guides.
3. On your Neon database, create a subscription to pull data from your Aurora/RDS instance.
4. Once you’re set, the replication process will begin, copying data from Aurora/RDS to Neon in the background. Monitor the process to ensure that data is replicating correctly.
5. When all data has been replicated and the databases are in sync, you can perform a controlled switch by redirecting your application to the Neon database. You can do this with minimal downtime by temporarily pausing write operations on the source, letting the final changes replicate, and then pointing your application to Neon.
6. Once the migration is complete and your application is running smoothly on Neon, you can disable the subscription and publication to stop replication.

Get migration help

We get it—migrations are scary. If you’d still like technical assistance with your migration, our team is here to help. Reach out to us anytime at support@neon.tech.