Aiven for PostgreSQL 13 performance on GCP, AWS and Azure [Benchmark]

Welcome to our latest benchmark figures for Aiven for PostgreSQL on AWS, GCP and MS Azure.

16 September 2021
Eero Tuomikoski
Eero Tuomikoski RSS Feed
Solution Architect, Pre-Sales at Aiven

At Aiven, we’ve run different PostgreSQL cloud performance benchmarks since 2016. In this update, we’ve compared write performance metrics for PostgreSQL 13.4 between Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure across four benchmarks.

Our four benchmarks measured and compared the performance of PostgreSQL 13.4 running on AWS, GCP and Azure in each of the following four Aiven managed PostgreSQL plan configurations: PG Benchmark graphs tables2


To examine performance, we measured the number of database transactions per second while vertically scaling up the nodes. This way the number of nodes remained the same, but the amount of CPUs, RAM and storage on each node increased.

We generated load using pgbench, which we ran on another VM in the same cloud and region. The load generator commands for each plan were as follows:

$ pgbench --client=<startup_plan> --jobs=2 --report-latencies --time=3600 --log --aggregate-interval=1 keepalives='1' keepalives_count='12' keepalives_idle='180' keepalives_interval='10' sslmode='require'

The variable for the startup plan being tested was the --client switch. The values for the four startup plans were, descriptively enough we hope, 4, 16, 32, and 64.

The load generator instance types used were as follows:

  • AWS: m4.large
  • GCP: n2d-standard-2
  • Azure: standardDS2v2

As in a production PostgreSQL (PG) setup, the local SSDs running PG used LUKS full-disk encryption with WAL archiving enabled. The PG instances under test were initialized as follows (shown here without connection parameters):

$ pgbench --initialize --scale=<scale> --quiet keepalives='1' keepalives_count='12' keepalives_idle='180' keepalives_interval='10' sslmode='require'

The --scale parameter was adjusted to accommodate each plan; in this case, the DB size was roughly double the size of RAM, with the possible values of 500, 1500, 2500, and 4500.

To minimize the effects of variable latency on our benchmark, we used a comparable central Europe region for each provider:

  • AWS: eu-central-1
  • GCP: europe-west3
  • Azure: germany-westcentral (* westeurope; see results below)

Finally, we concluded the benchmark by calculating the average mTPS/$ per PG plan according to publicly available pricing information.

Transactions per second

Aiven Startup-4 plans

PG Benchmark graphs

Aiven Startup-16 plans

PG Benchmark graphs2

Aiven Startup-32 plans

PG Benchmark graphs3

Aiven Startup-64 plans

For the startup-64 plan on Azure in germany-westcentral region, we noted abnormally low performance. An identical test on westeurope was more in line with expectations, where the instance type was standardl8sv2 with fewer CPU cores, but higher RAM. PG Benchmark graphs4

mTPS/$ average per service plan size

Performance value was calculated as an average of millions of transactions per second per dollar or (mTPS/$) for each cloud provider.

We found that, overall, the performance/cost difference between cloud providers quite substantially favored Google. As before, Startup-4 plans were an exception:

PG Benchmark graphs tables1

Wrapping up

Many factors affect PostgreSQL performance, including latency differences between the regions, but didn’t differentiate for in this benchmark. There is also another factor to consider, which is variably-sized workloads. In this benchmark, the basic idea was to generate a significant load on tested services by using a large number of parallel client connections.

We always recommend that standalone PostgreSQL users identify performance bottlenecks and tune their database configuration, workload or hardware configuration to optimize. However, in our managed PostgreSQL services, PostgreSQL system parameters come preconfigured for typical workloads, and you can try out different hardware configurations by choosing different Aiven for PostgreSQL plans.

We also recommend you to run your own benchmarks, and we will soon publish our Terraform benchmarking scripts that allow easily repeating similar performance tests.

We’ll be publishing more benchmarks like these soon, so stay tuned!

Not using Aiven services yet? Sign up now for your free trial at!

In the meantime, make sure you follow our changelog and blog RSS feeds or our LinkedIn and Twitter accounts to stay up-to-date with product and feature-related news.

orange decoration
yellow decoration

Start your free 30 day trial!

Build your platform, and throw in any data you want for 30 days, with no ifs, ands, or buts.

orange decoration
yellow decoration

Start your free 30 day trial!

Build your platform, and throw in any data you want for 30 days, with no ifs, ands, or buts.


Aiven for Apache KafkaAiven for Apache Kafka ConnectAiven for Apache Kafka MirrorMaker 2Aiven for M3Aiven for M3 AggregatorAiven for Apache CassandraAiven for OpenSearchAiven for PostgreSQLAiven for MySQLAiven for RedisAiven for InfluxDBAiven for Grafana

Let‘s connect

Aiven for Apache Kafka, Aiven for Apache Kafka Connect, Aiven for Apache Kafka MirrorMaker 2, Aiven for M3, Aiven for M3 Aggregator, Aiven for Apache Cassandra, Aiven for OpenSearch, Aiven for PostgreSQL, Aiven for MySQL, Aiven for Redis, Aiven for InfluxDB, Aiven for Grafana are trademarks and property of their respective owners. All product and service names used in this website are for identification purposes only and do not imply endorsement.