Graviton2 versus Graviton4

Posted byJeremy⋅August 3, 2025⋅2 Comments

Filed Under amazon,aws,cloud,cpu,ec2,performance,postgres,PostgreSQL,processor,technology

Just a short post, because I thought this was pretty remarkable. Below, I have screenshots showing the CPU utilization of two AWS instances inus-west-2 which are running an identical workload.

They are running the CloudNativePG playground, which is a production-like learning and testing environment (all running virtually inside the single ec2 instance, which can be easily started and stopped or terminated and recreated). The standard CNPG playground setup consists of two Kubernetes clusters namedkind-k8s-eu andkind-k8s-us. Each Kubernetes cluster contains a CloudNativePG cluster with HA between three postgres replicas running across three nodes/servers locally, and then there is cross-cluster replication from the EU cluster (primary) to the US cluster (standby).

What jumped out at me was the huge difference in CPU utilization! The Graviton2 instance runs maybe 40% utilization while the Graviton4 instance runs around 10% utilization.

I just now checked theAWS on-demand pricing page, andm6g.xlarge is $0.154/hr whilem8g.xlarge is $0.17952/hour. That is a 16.6% increase in price, and for this particular workload it could be as much as a 300% increase in performance. At a fleet level, this should translate into significant cost saving opportunities if anyone adopted Graviton2 and if they are able to scale down overall instance counts based on better performance of newer generation chips.

Honestly, 40% utilization is technically fine for most of my own Kubernetes and Postgres experiments… but the 16.6% price increase is just low enough that I’ll probably start using the m8g instances anyway. 🙂

Things like this also underscore why it’s so hard to compare processors… how can we compare across different families, when we see differences like this between generations WITHIN a family?! Besides that, the total number of different processor choices we have today is overwhelming, taking into account all the different providers in the market. It’s a tough job.

About Jeremy

Building and running reliable data platforms that scale and perform.about.me/jeremy_schneider

View all posts by Jeremy»

« Collation Torture Test versus Debian

Run Jepsen against CloudNativePG to see sync replication prevent data loss»

Discussion

2 thoughts on “Graviton2 versus Graviton4”

Why not using the m8g.large or even m8g.medium, to save some money and still have better or comparable performance?
LikeLike
Posted byElevarq |August 4, 2025, 11:30 am
Reply to this comment
- @elevarq – yep i was also thinking about trying this 😀 … i want the 16G memory so need to switch families, but i’ll probably still save some money
  LikeLike
  Posted byJeremy |August 4, 2025, 12:33 pm
  Reply to this comment

Leave a New CommentCancel reply

This site uses Akismet to reduce spam.Learn how your comment data is processed.

Disclaimer

This is my personal website. The views expressed here are mine alone and may not reflect the views of my employer.I am currently looking for consulting and/or contracting work in the USA around the oracle database ecosystem.

contact:312-725-9249 orschneider @ ardentperf.com