Performance comparison: Amazon Aurora vs. Amazon Aurora Serverless v2
Serverless technologies are everywhere these days, and databases are no exception. AWS Aurora Serverless V2 has been with us for some time and is already a viable option for use in more varied production environments than its predecessor. The goal of the comparison is to know if there is any difference from the performance perspective between an Amazon Aurora or an Amazon Aurora Serverless v2 with the same amount of memory, both PostgreSQL compatible.
We will use two AWS Lambda Functions that share the same code base. The first points to an Amazon Aurora database, and the other to an Amazon Aurora Serverless v2 database. We will consider the following scenarios during this performance comparison:
db.t3.medium vs. 2 ACU: Using 1, 2, 5, 10, 50,100, 150, 200, and 250 concurrent connections.
db.t3.large vs. 4 ACU: Using 25, 50, 100, 150, 300, and 400 concurrent connections.
db.r5.large vs. 8 ACU: Using 300, 450, 600, 750, and 1000 concurrent connections.
Every test will send requests to the AWS Lambda Functions for ten minutes.
Response Time Distribution
Let's explain the chart above. The first row shows that using one concurrent user, 49.4% of the request to the provisioned instance are in the interval of 100ms-150ms, while only 42% of the requests to the serverless instance are in the same interval. Moving up in the chart, we notice that the response time distributions are similar until the 50 concurrent connections.
In this scenario, the response time distributions are even until the 100 concurrent connections. Between 150 and 450 concurrent connections, the provisioned instance performs much better.
The last scene presents the same behavior. This time 750 concurrent connections are the limit where both instances have similar response time distributions.
Average Response Time
The following charts will confirm the behavior previously detected:
This comparison only covers three types of provisioned instances but we think that is enough to suspect that those perform better than their corresponding serverless version in the presence of a high number of concurrent connections. That could mean that under a load of 1000 concurrent connections, a db.r5.large instance with its 16 GB of memory could perform as a 9 or 10 ACU serverless instance and not as an 8 ACU instance (remember that every ACU is around 2 GB of memory). Thanks, and happy coding.