Databases on AWS: Amazon Aurora V1 to V2 upgrades
As we have already commented in our last post on relational databases, AWS Aurora It is a high-performance, scalable, monitored and easy-to-use cloud service, fully managed, support MySQL and PostgreSQL
Below we present the improvements to this service, which allow database management to be much more optimal and resilient.
If you found this post interesting, we invite you to download our free Ebook «How to migrate to Amazon Web Services?
Amazon Aurora V1 to V2 Improvements
Among the constant improvements that AWS makes to its service, it introduced a new Amazon Aurora modality with different improvements and differences depending on the use case, Aurora Serverless V2 It is a serverless mode that allows scaling to hundreds of thousands of transactions in a fraction of a second. 
.
Furthermore, supports a wide range of jobs, from test environments or applications with infrequent workloads to applications that require high scalability and availability y is compatible with other Aurora features.
1. Scalability
Aurora Serverless V1: It scales automatically, but it cannot do so while there are connections to the database to scale, you have to wait until there are no ongoing transactions or configure the database to scale independently.
Aurora Serverless V2: Version 2, on the other hand, offers improvements in scalability, with instances automatically scaling up or down in milliseconds based on application load.
2. Failover and read replicas
Aurora V1: An Aurora Serverless V1 cluster operates as a single read/write instance with no read replicas. In the event of a failure, a new master will be created, but during this time it will not have a database.
Aurora V2: An Aurora Serverless cluster has failover happens and read replica capabilities of regularly provisioned Aurora clusters. If the master fails, one of the read replicas acts as a hot spare and application disruption is minimal.
3. Clusters
The clusters of Aurora V1 They are completely separated from regular provisioned databases and cannot be natively mixed.
For its part, Aurora V2 allows you to use a combination of instances of Provisioned databases and serverless database instances in the same cluster, allowing you to build burst capacity into your traditional database clusters.
4. Data API
With Serverless V1 we had a “data API” which exposed the serverless database through a simple HTTP endpoint and access to the endpoint was granted with IAM permissions.
However, Serverless V2 does not have data API, making it harder to use with Lambda functions.
5. Zero scaling
Aurora V1 can climb up to 0 ACU and automatically scale when requests are made.
Instances of Aurora V2 They do not allow scaling to 0 but up to 0'5 ACU and only scales up to 256GB of RAM and not 768 RAM.
6. Multi AZ
One of the limitations that customers found with Aurora V1 It was the unavailability from MultiA-Z. To this end, they have been integrated into version 2 of Aurora, Muli-AZ clusters that can distribute the database instances of a cluster across multiple zones availability. Setting up a Multi-AZ cluster helps ensure business continuity.
In conclusion, Aurora V1 is a recommended choice for infrequent, intermittent, or unpredictable workloads, such as lightly used applications, Aurora V2 is more focused on database workloads, from development and test environments, to those more demanding critical business applications..
At apser we have experts to help you with your migration process to the cloud through a personalized road map. Contact UsWe will be delighted to hear about your project.
