AWS Graviton vs Intel on Aurora PostgreSQL benchmark

I benchmarked Graviton and Intel instances on Aurora PostgreSQL with pgbench, measuring throughput and cost-per-transaction. Intel won on general-purpose, Graviton won on burstable.

Photo by Kaleidico / Unsplash

I kept hearing the same claim: "Graviton gives you up to 40% better price-performance than x86." AWS says it [4]. Blog posts repeat it. But when I looked for hard numbers on managed databases, specifically Aurora PostgreSQL [6], I found almost nothing. Most benchmarks out there test raw EC2 compute [1], [4] or serverless functions [3]. Not a managed database where the engine, the virtualization layer, and the architecture all interact in ways that are hard to predict.

So I ran my own benchmarks. This is what I found.

Why I did this

I was working on a research project at Telkom University, and we had a simple question: if you're an architect picking an Aurora PostgreSQL instance today, should you go Graviton (ARM64) or Intel (x86_64)? This work was presented at 14th ICoICT 2026. This blog post is adapted from the conference paper version with same data, less formal.

The answer turns out to depend on which instance family you're looking at. Not just the architecture. The family and the generation matter just as much.

Honestly, I expected Graviton to win across the board. The marketing made it sound that way. But the numbers told a different story.

The setup

I ran all tests in us-east-1 (Northern Virginia). The database was Aurora PostgreSQL 17.4, using the default parameter group. No custom tuning. I wanted a baseline that any engineer could reproduce without spending days tweaking configs.

The loader was a t3.medium EC2 instance running Ubuntu 24.04 with pgbench 16.11. It sat in the same availability zone as the database to keep network latency out of the picture.

I initialized a single pgbench [13] database with scale factor 500. That gives you about 8 GB of data, which is enough to overflow the buffer cache on smaller instances and force real I/O. Each test ran three times for 120 seconds with prepared statements. I took the mean of the three runs. The coefficient of variation stayed under 3% across all tests, which is consistent with what other cloud benchmarking studies have found [14].

I tested four concurrency levels: 16, 32, 64, and 128 clients. And three workload types: the default TPC-B-like mix, select-only, and write-intensive (simple-update).

The instances I compared

I picked two comparisons that reflect real decisions architects make.

General-purpose (M-series): db.m7g.large (Graviton3) vs db.m7i.large (4th Gen Intel Xeon Scalable, Sapphire Rapids). Both have 2 vCPUs and 8 GiB RAM. Both sit on the AWS Nitro System. These are the latest generation from each architecture [9]. At the time of testing, db.m7i.large cost $0.178/hr and db.m7g.large cost $0.168/hr in us-east-1. A 6% difference.

Burstable (T-series): I compared db.t4g (Graviton2) against db.t3 (Intel) [10]. This is not a generation-matched comparison. The T4g instances are newer than the T3 instances they commonly replace [8]. But that's the point: if you're on T3 today, T4g is what AWS offers as the upgrade path. I tested both medium (2 vCPU, 4 GiB) and large (2 vCPU, 8 GiB) sizes. The T4g instances are 10-11% cheaper per hour than the equivalent T3 sizes. All T-series instances were launched with Unlimited mode enabled [12], so CPU credits were not a bottleneck during the benchmarks.

I should note: AMD EPYC instances were not available in the M7 generation for Aurora PostgreSQL at the time, so the comparison is purely Intel vs Graviton.

M-series: Intel wins, and not by a little

The db.m7i.large (Intel) beat the db.m7g.large (Graviton3) in every workload, at every concurrency level.

In the default mixed workload, the Intel instance averaged 2,624.93 TPS. The Graviton instance averaged 1,917.01 TPS. That's a 36.9% gap. The advantage ranged from 29.3% at 64 clients to 48.7% at 16 clients.

The gap got even wider on the select-only workload. Intel averaged 34,493.43 TPS vs Graviton's 23,574.45 TPS. A 46.3% advantage. At 128 clients, Intel hit 68.2% more throughput. The Graviton instance actually started degrading at higher concurrency. It peaked at 25,351.1 TPS with 32 clients, then dropped to 20,215.3 TPS at 128 clients. The Intel instance just kept scaling.

For the write-intensive workload, Intel maintained a 35.7% average advantage. Both instances scaled well here, but Intel was consistently ahead.

But here's the catch: the Intel instance costs 6% more per hour. So does the higher throughput justify the higher cost?

I calculated the cost-per-transaction (CPT) by dividing the price per second by the average TPS. Lower CPT is better. For the M-series default workload:

db.m7i.large (Intel): $18.84 × 10⁻⁹ per transaction
db.m7g.large (Graviton3): $24.35 × 10⁻⁹ per transaction

Intel was 22.6% cheaper per transaction, despite the higher hourly rate. The throughput advantage more than compensated for the price difference.

Figure 1: M-series performance across three workloads. Select-only TPS scaled by 10× for visualization.

T-series: Graviton takes the lead

The burstable tier told a different story. The Graviton2-based T4g instances consistently outperformed the older Intel T3 instances.

For the medium instances, the db.t4g.medium averaged 990.12 TPS in the default workload vs db.t3.medium's 898.16 TPS. A 10.2% advantage. The gap grew with concurrency, peaking at 13.0% with 64 clients.

Figure 2: T-series medium performance across three workloads. Select-only TPS scaled by 10× for visualization.

The large instances showed an even bigger gap. db.t4g.large averaged 1,155.73 TPS vs db.t3.large's 922.13 TPS. That's a 25.3% advantage. At 32 clients, the gap hit 28.8%.

The select-only workload on large instances showed the biggest difference. db.t4g.large hit 7,732.94 TPS mean vs db.t3.large's 6,254.90 TPS. A 23.6% advantage.

Figure 3: T-series large performance across three workloads. Select-only TPS scaled by 10× for visualization.

The cost-per-transaction numbers were just as clear:

db.t4g.medium: $18.24 × 10⁻⁹ (18.1% better than T3)
db.t3.medium: $22.27 × 10⁻⁹
db.t4g.large: $31.01 × 10⁻⁹ (29.0% better than T3)
db.t3.large: $43.68 × 10⁻⁹

The T4g instances are both faster and cheaper. That's the best kind of win.

Figure 4: Cost-per-transaction (CPT) comparison across all instances. Lower is better. ARM instances in blue, Intel in coral. Burstable instances shown with hatched pattern.

Why the results flip between tiers

This surprised me at first. Why would Graviton lose in M-series but win in T-series?

I think there are two things going on.

First, the microarchitecture. In the M-series, we're comparing Graviton3 against Intel Sapphire Rapids. Both are the latest from their respective vendors. And on this specific workload, Aurora PostgreSQL OLTP, Intel's microarchitecture simply performs better. A previous study by Loghin [15] found that ARM servers spend roughly twice as much time in Linux kernel system calls compared to Xeon servers, and show lower per-core performance due to less optimized software. That lines up with what I saw.

Second, the T-series comparison is cross-generational. The T4g instances run Graviton2, which is a newer microarchitecture than the Intel Xeon processors in T3 instances (Skylake-SP or Cascade Lake, depending on what AWS assigns you). You're getting a generational leap in CPU design, a more modern memory subsystem, and better process node. All of that translates to higher throughput, and AWS prices it lower too.

I can't separate how much of the T-series advantage comes from the ARM architecture vs just being a newer chip. The instance types available don't let me isolate that. But as a practical matter, it doesn't matter. If you're on T3 today, moving to T4g gives you more performance for less money. The reason is academic.

This is not a universal truth. It's what I observed in one region, on one database engine, with one benchmark tool. But here's what I'd say:

If you're running a production Aurora PostgreSQL database on general-purpose instances, and performance matters, go with Intel M7i. The db.m7i.large gives you 29-68% more throughput for only 6% more cost. The cost-per-transaction is 22.6% better. That's a clear win.

If you're on T3 instances today for dev, staging, or variable workloads, migrate to T4g. You'll get 10-25% more throughput and 18-29% better cost-per-transaction. There's no downside I could find.

Always consider instance generation alongside architecture. Don't just ask "ARM or x86?" Ask "which specific instance, from which generation, for which workload?"

What I didn't test

Plenty. This study has real limits.

I only used pgbench with the standard TPC-B-like workload. Something like TPC-C would be a better simulation of real-world OLTP. I didn't touch Aurora-specific parameter tuning. Maybe there are configs that favor Graviton more. I didn't test storage-optimized instance families like the I/O-optimized ones. I didn't monitor CPU telemetry like credit balances or thermal throttling on the burstable instances, so I can't confirm exactly what was happening under the hood.

I only tested in us-east-1. Different regions might have different underlying hardware and resource overcommitment practices, which can introduce variable CPU steal times [16]. I only tested Aurora PostgreSQL. Aurora MySQL might behave differently.

I also didn't test AMD instances, since they weren't available in the M7 generation for Aurora at the time.

If someone else picks this up, those are the gaps I'd fill first. I might do a follow-up with TPC-C if I get the time and budget for it. But for now, this is what I have. Take it as one data point, not the final word.

References

[1] J. Tharwani and A. A. Purkayastha, "Cost-Performance Evaluation of General Compute Instances: AWS, Azure, GCP, and OCI," 2024, arXiv. doi: 10.48550/ARXIV.2412.03037.

[2] B. Varghese and R. Buyya, "Next Generation Cloud Computing: New Trends and Research Directions," 2017, arXiv. doi: 10.48550/ARXIV.1707.07452.

[3] X. Chen, L.-H. Hung, R. Cordingly, and W. Lloyd, "X86 vs. ARM64: An Investigation of Factors Influencing Serverless Performance," in Proceedings of the 9th International Workshop on Serverless Computing, Bologna, Italy: ACM, Dec. 2023, pp. 7–12. doi: 10.1145/3631295.3631394.

[4] R. Mathá, D. Kimovski, A. Zabrovskiy, C. Timmerer, and R. Prodan, "Where to Encode: A Performance Analysis of x86 and Arm-based Amazon EC2 Instances," 2021, arXiv. doi: 10.48550/ARXIV.2106.06242.

[5] M. D. Lima, L. Teylo, and L. Drummond, "An Analysis of Performance Variability in AWS Virtual Machines," in Anais do XXV Simpósio em Sistemas Computacionais de Alto Desempenho (SSCAD 2024), Brasil: SBC, Oct. 2024, pp. 312–323. doi: 10.5753/sscad.2024.244526.

[6] A. Verbitski, A. Gupta, D. Saha, M. Brahmadesam, K. Gupta, R. Mittal, S. Krishnamurthy, S. Maurice, T. Kharatishvili, and X. Bao, "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases," in Proceedings of the 2017 ACM International Conference on Management of Data, Chicago, IL, USA: ACM, May 2017, pp. 1041–1052. doi: 10.1145/3035918.3056101.

[7] R. Goel, "Amazon Aurora: Insights and Benchmarks for Contemporary Application Scaling," IJCA, vol. 186, no. 70, pp. 29–31, Mar. 2025, doi: 10.5120/ijca2025924554.

[8] G. C. F. Ferrari, V. Filho, and M. Castro, "Comparing Burstable and On-Demand AWS EC2 Instances using NAS Parallel Benchmarks," in Anais da XXIV Escola Regional de Alto Desempenho da Região Sul (ERAD-RS 2024), Brasil: SBC, Apr. 2024, pp. 61–64. doi: 10.5753/eradrs.2024.238733.

[9] Amazon Web Services, "DB instance class types — General-purpose instances," [Online]. Available: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.Types.html#Concepts.DBInstanceClass.Types.general-purpose. Accessed: Feb. 9, 2026.

[10] Amazon Web Services, "DB instance class types — Burstable performance instances," [Online]. Available: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.Types.html#Concepts.DBInstanceClass.Types.burstable. Accessed: Feb. 9, 2026.

[11] M. U. Kalay, "Concurrency Challenges in Database Systems: A Focus on Postgresql," Bilgisayar Bilimleri ve Teknolojileri Dergisi, vol. 6, no. 1, pp. 1–16, Jul. 2025, doi: 10.54047/bibted.1574178.

[12] Amazon Web Services, "Unlimited mode for burstable performance instances," [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html. Accessed: Mar. 17, 2026.

[13] PostgreSQL Global Development Group, "PostgreSQL: Documentation: 16: pgbench," [Online]. Available: https://www.postgresql.org/docs/16/pgbench.html. Accessed: Apr. 2, 2026.

[14] S. Henning, A. Vogel, E. Perez-Wohlfeil, O. Ertl, and R. Rabiser, "When Should I Run My Application Benchmark? Studying Cloud Performance Variability for the Case of Stream Processing Applications," in Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering, Trondheim, Norway: ACM, Jun. 2025, pp. 400–410. doi: 10.1145/3696630.3728563.

[15] D. Loghin, "Are ARM Cloud Servers Ready for Database Workloads? An Experimental Study," IEEE Trans. Cloud Comput., vol. 12, no. 3, pp. 818–829, Jul. 2024, doi: 10.1109/TCC.2024.3393895.

[16] A. Uhlig, I. Braun, and M. Wählisch, "The SAP Cloud Infrastructure Dataset: A Reality Check of Scheduling and Placement of VMs in Cloud Computing," in Proceedings of the 2025 ACM Internet Measurement Conference, Madison, WI, USA: ACM, Oct. 2025, pp. 746–760. doi: 10.1145/3730567.3764480.