Performance comparison: Amazon Aurora vs. Amazon Aurora Serverless v2

Somebody who likes to code
Search for a command to run...

Somebody who likes to code
No comments yet. Be the first to comment.
Google processes tens of thousands of code changes every day across a codebase of hundreds of millions of lines. The secret isn't magic tooling — it's a documented, principled approach to code review

Amazon Simple Notification Service (SNS) looks straightforward on the surface — publish a message, deliver it to subscribers — but the gap between a topic that "works in dev" and one that is productio

Amazon Simple Queue Service (SQS) is deceptively simple to get started with, but surprisingly easy to misconfigure in ways that cause silent message loss, runaway costs, duplicate processing storms, o

HTTP API is the right default choice for the majority of .NET serverless workloads. At 70% less cost than REST API, lower latency, and native JWT authorization, it covers most production requirements

AWS Lambda has become a cornerstone of modern serverless architectures, but writing a function that "just works" is very different from writing one that is performant, cost-effective, secure, and read

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.

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.
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.