GCP AlloyDB VS AWS Aurora Performance Comparison

In this article we go over an independent benchmark of GCP AlloyDB vs AWS Aurora

AWS Aurora and GCP AlloyDB are cloud native, PostgreSQL compatible databases. They offer performance that is competitive with traditional, single-node databases (such as PostgreSQL or MariaDB) while offering extra durability and availability guarantees.

In this article, I compare the performance of the two database services using Reserva, a custom benchmarking tool I created to simulate a high volume digital payments system.

AlloyDB is 13% faster than Aurora in my most recent tests. I would recommend using it if you are already on GCP, but this difference isn’t large enough to recommend migrating existing workloads.

Reserva

Reserva is a system I made to simulate a streamlined, high volume payments processing system. It is written in Go and supports arbitrary amounts of concurrency.

On start, Reserva loads all users and authentication tokens into memory, then attempts to make as many funds transfers as possible in a loop. Each funds transfer requires 4 round trips to the database and touches 6 tables. The workflow is as follows:

DB is queried to authenticate and authorize the user who is requesting payment.
DB is queried to get information about the card used and account to be debited.
DB is queried to authenticate and authorize the user who will approve or deny the payment request.
DB is queried to update both account balances and record the payment.

Reserva allows you to select whether or not you want deletes to be part of the workload. The results on this page do include deletes as part of the workload.

Benchmark setup

First, I analyzed the options for creating AlloyDB and Aurora instances in each cloud platform. I settled on two machines that should provide roughly equal raw-metal performance. Below is a description of each machine’s key configuration parameters.

AlloyDB configuration

I deployed AlloyDB in GCP’s London region with the following settings:

2 vCPUs
16 GB of RAM
Single zone
PostgreSQL 16 compatible (preview)

Below is a screenshot of GCP’s UI after setup:

Aurora configuration

I deployed Aurora in AWS’ London region with the following settings:

db.r7g.large instance
- 2 vCPUs
- 16 GB RAM
No Aurora replica
PostgreSQL 16.4 compatible
Aurora I/O-Optimized disk

Below is a screenshot of AWS’ UI after setup:

Cost comparison

Both databases are estimated to cost around $0.35 per hour for compute and memory resources, with storage costing some amount extra, depending on usage. I would guess that a busy production instance with lots of data (plus backups) would end up costing around $0.50 per hour, which comes out to $360 per month.

AlloyDB cost estimate

AlloyDB charges $0.15 per hour for the CPUs and $0.20 per hour for the RAM. I wish they gave an option to use less than 16GB of RAM, like Aurora does.

They also charge $0.00047 per GB for main storage, and $0.00016 for backup storage.

Here is a screenshot of the cost estimate provided on GCP’s UI:

Aurora cost estimate

AWS’ UI doesn’t break out the CPU, RAM, and storage cost like GCP’s does, but it ends up being around the same price per hour. $262 / 24 / 30 (to get hourly cost) comes out to around $0.36 per hour.

Here is a screenshot of the cost estimate provided on AWS’ UI:

Populating data

Next we run the DB preparation SQL scripts to create:

10 banks with access to the payments system and corresponding users + permissions + auth tokens
1,000,000 accounts, each with a corresponding payment card

You can see the SQL setup scripts, along with the rest of the code, on Reserva’s Github page.

The test

I ran Reserva with the following settings for both databases:

25 concurrent requests at a time
Maximum of 25 open database connections (idle or active)
2 hour duration
Deletes enabled as part of the workflow

At the end of the test, I executed the following queries to show how many payments were made over the course of the hour. The results of those queries are visualized below.

Aggregation query

SELECT
    DATE_TRUNC('minute', CREATED_AT) AS MINUTE,
    COUNT(*) AS NUMBER_OF_TRANSFERS
FROM
    TRANSFERS
GROUP BY
    MINUTE
ORDER BY
    MINUTE;

Results

As you can see, AlloyDB was faster overall, and there didn’t seem to be any convergence happening.

It is worth noting that because deletes were enabled in this run, 1 out of every 20 funds transfer loops also deletes a random transfer. So, the actual amount of fund transfers processed for each database is 5% higher. For comparison purposes, the results are still valid.

I also aggregated the last hour of the test in a spreadsheet to create a simple “transfers per minute” bar chart, shown below. AlloyDB is 23% faster in the time frame that I selected.