Amazon Aurora PostgreSQL can be a great option for businesses looking to upgrade their existing database. Whether you are reaching end of support for your existing database solution, looking to get off an older technology stack, or chasing the benefits of a newer or cloud-optimised database, Aurora PostgreSQL offers numerous benefits from a business and technical point-of-view.
Recently, a Client of ours was facing the decision to either perform an in place upgrade of their enterprise application’s existing postgres RDS database or use Amazon’s Data Migration Service (DMS) to migrate to a new database instance. We investigated a number of options before determining a migration to Aurora Postgres to be the best approach for the Client’s situation.
This blog discusses the benefits of the Aurora Postgres database, outlines the pros and cons of our Client’s use case for migrating to Aurora, and provides a strategy for migration from standard Postgres to Aurora PostgreSQL.
(Hint: To see more blogs on AWS tools like Eventbridge and CloudWatch, check out our Cloud Enablement Page).
Benefits of Aurora Postgres Database
Amazon Aurora is a cloud-based relational database that offers both Postgres and MySQL compatible versions. In comparison with a standard Postgres or MySQL RDS database, Amazon Aurora is specifically designed for the cloud and has improved scalability and speed (3 times faster than a standard postgres database, or 5 times faster than MySQL).
Aside from better performance and scalability, Aurora Postgres is also more reliable than many other database options. High availability is guaranteed with data replicated automatically across 3 AWS availability zones. It also offers fault tolerant and self healing storage, instance monitoring and recovery of the database in the event of failure.
One of Aurora’s biggest business advantages, however, is the chance to significantly lower costs when compared to traditional databases. Similarly to most AWS services, there is no lock-in bundle for pricing and resources – the database will scale up and down as required and you will only ever pay for what you are using. With our Client use case, this saved a considerable amount of cost that was previously being spent on unused storage after a significant data cleanup.
Key Upgrade Options
For our Client we conducted research into the potential upgrade options before choosing Aurora Postgres. The pros and cons of the two main options for our Client’s use case are summarised below*.
*There was also the possibility of replicating automatically to Aurora Postgres, but the current Postgres version did not allow for it.
The drivers for our Client’s upgrade were that the existing database was reaching end-of-support, and they were seeking the benefits of better scalability and cost optimisation. The application is also a mission critical system meaning any downtime during the upgrade was unacceptable.
Naturally, moving from a Postgres database to Aurora Postgres means an easier transition than moving from a different type of database altogether. Amazon DMS does however support data migration between different database types.
There was also the added benefit of the existing database already being in the cloud, and on AWS services. AWS does support migrating from on premise to AWS cloud using DMS (and the other way round).
Migrating to Aurora Postgres from Postgres RDS
Upgrading to the Aurora Postgres from an existing Postgres RDS can be a relatively easy transition once the decision has been made as there is a lot of similarity between the two databases.
The below table is a summary of the steps we took to upgrade to Aurora.
High Level Process
The application continued to use the old database all the way until cutover. Data migration occurred on the live running system, and there was no downtime due to migration.
We also had two rollback options. The first was the original database, which we could rollback to immediately if there were any problems with the release. The second was a temporary Postgres RDS that we set up as a ‘fall forward’ rollback option. We would roll back to this if needed within a two week period. For this we used Amazon DMS to replicate data from the new Aurora database to the temporary one (and was exactly the same version as the original). This rollback option would ensure that no data loss occurred after cutover with the running system.
Moving from different database platforms to Aurora
I mentioned earlier that a motivation for the move to Aurora may be the desire to get off another technology stack and onto AWS. This can be a bit more of a challenge in itself, and can become a very different conversation if moving off, say, an Oracle on-premise and into the cloud for the first time. The cost and performance benefits of Aurora (as well as those of the cloud in general) would still apply, but it is important to note that there may be application changes required. This is because different database platforms offer different functions, and query execution may differ between them. This would require application changes and a full regression test of the application.
