ARM vs x86_64 on AWS: Cost-Performance of MariaDB OLTP

I kept hearing the same claim: "ARM instances are just as fast as x86_64 and 30% cheaper." AWS says it [3]. Cloud cost calculators repeat it. But cloud computing has changed how we deploy databases. The shift to on-demand infrastructure means architecture choices now have a direct dollar impact [1]. When I looked for hard numbers on databases, specifically MariaDB, I found almost nothing. Most benchmarks out there test raw compute or video encoding. Not a database where the CPU, the storage layer, and the transaction engine 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 deploying MariaDB for OLTP on AWS, should you go ARM (Graviton3) or x86_64 (AMD EPYC)? This work was presented at 3rd ICoABCD 2025. This blog post is adapted from the conference paper version: same data, less formal.

The two big architectures on AWS are x86_64 (historically Intel and AMD) and ARM (AWS Graviton) [2]. Graviton3 processors are built on ARMv8.4 and are marketed as cheaper and more efficient [3]. AMD EPYC represents the established x86_64 family with proven compatibility and reliability [4].

For OLTP workloads, the database is usually the bottleneck. OLTP systems power things like fraud detection, e-commerce, and social media [6]. They need consistent throughput and low latency under lots of concurrent requests [7]. So the architecture you pick matters a lot.

Honestly, I expected ARM to win. The marketing made it sound that way. And spoiler: it did win on cost. But the performance story was more nuanced than I expected.

The setup

I ran all tests in us-east-1. Four EC2 instances total, all in the same VPC, subnet, and availability zone to keep network latency out of the picture.

The database was MariaDB 10.11.13, installed from the default Ubuntu 24.04 LTS package repo. MariaDB is a widely adopted open-source relational database [8], and it supports both ARM and x86_64 without any code changes [9]. That made it a clean platform for this comparison. No custom tuning. I wanted a baseline that any engineer could reproduce without spending days tweaking configs. The only changes I made were bumping max_connections to 512 and binding the server to 0.0.0.0 so the benchmark client could reach it.

The loader was a separate EC2 instance running SysBench 1.0.20 with LuaJIT 2.1.0-beta3. It sat in the same availability zone as the database. All traffic went over private IPs.

I used the standard SysBench OLTP workloads: read-only, write-only, and mixed read-write [5]. The dataset was 50 tables, each with 100,000 rows. I tested from 1 thread up to 192 threads, stepping by 16. Each test ran for 120 seconds.

The instances I compared

I picked one comparison that reflects a real decision an architect would make: latest-generation compute-optimized instances from each architecture.

c7g.large (ARM): AWS Graviton3, 2 vCPUs, 4 GiB RAM, $0.0725/hr [10].

c7a.large (x86_64): AMD EPYC, 2 vCPUs, 4 GiB RAM, $0.10264/hr [10].

Same vCPUs, same RAM, same network bandwidth. The only real difference is the CPU architecture. And the price. The ARM instance is about 29.4% cheaper per hour.

Storage was gp3 across the board: 8 GB, 3,000 IOPS, 125 MB/s throughput.

Read-only: ARM has a real lead at low concurrency

ARM had a clear advantage in single-threaded read performance. At 1 thread, ARM processed 50,080 transactions vs x86_64's 40,929. That's a 22.4% gap.

But as concurrency went up, the gap disappeared. At 16 threads, both hit around 209,000 transactions. From 32 threads upward, the two architectures were basically tied. At 192 threads, x86_64 actually pulled slightly ahead: 205,960 vs 203,785.

Latency scaled predictably for both. At 1 thread, ARM had 3.89 ms (95th percentile) vs x86_64's 4.57 ms. By 192 threads, both were around 290 ms.

So for read-heavy workloads, ARM wins if you're running at low concurrency. But if you're saturating the instance, it doesn't matter.

Write-only: nobody wins, writes are just slow

Write workloads are harder on databases. Lock contention, disk I/O, transaction serialization. All of that shows up in the numbers.

ARM had a small throughput advantage in the mid-range (32 to 80 threads), but nothing worth bragging about. At 1 thread, ARM did 7,001 transactions vs x86_64's 6,428. At higher concurrency, the gap was negligible.

Latency for write workloads was much worse than read. At 1 thread, both were around 25 ms. By 48 threads, latency passed 1,200 ms. By 192 threads, it hit over 10 seconds for both.

At this point, the CPU isn't the bottleneck anymore. The database engine itself is the limit, handling locks and disk writes. The architecture barely matters.

Mixed read-write: same story as read-only

The mixed workload looked a lot like the read-only pattern. ARM had a small advantage at low concurrency (20,838 vs 19,219 transactions at 1 thread). At higher concurrency, both architectures converged.

Latency sat between the read-only and write-only ranges. At 1 thread, iaround 8 ms for both. At 192 threads, around 1,000 ms.

So here is the raw performance summary: ARM wins at low concurrency, especially for reads. At high concurrency, both architectures deliver the same throughput. The CPU stops being the bottleneck. Memory bandwidth, storage I/O, and database locking take over.

If you only look at raw performance, the choice doesn't matter much unless you're running at low thread counts. But that's only half the story.

The cost angle: ARM wins, and it's not close

Raw performance is one thing. But in the cloud, you pay by the hour. An instance that's 5% slower but 30% cheaper might still be the better deal.

I calculated the cost per transaction (CPT). Take the price per second, divide by transactions per second. Lower CPT means you get more work done for the same money.

The ARM instance costs $0.0725/hr. The x86_64 instance costs $0.10264/hr. That's a 29.4% price difference.

ARM had a lower CPT at every concurrency level. At 1 thread, ARM was 34.8% cheaper per transaction. That's the compounding effect of better single-threaded performance plus lower hourly cost. Both advantages stack in the same direction.

At higher concurrency, the CPT advantage stabilized at about 29.4%. This makes sense. At high concurrency, both architectures have similar throughput, so the cost advantage comes almost entirely from the lower hourly price. The 29.4% CPT gap matches the 29.4% price gap almost exactly.

The same trend held for read-only and write-only workloads. I'm not showing those charts to keep things short, but the pattern is consistent. ARM gives you more transactions per dollar, period.

Why ARM wins on cost but not raw performance

This is the part that surprised me. ARM wins on cost, but the raw performance is basically a tie at high concurrency. Why?

I think the answer is simple. The ARM instance is 29.4% cheaper. And at high concurrency, it delivers the same throughput. So the cost advantage translates directly into a CPT advantage. There's no magic here. It's just cheaper hardware doing the same work.

The single-threaded performance advantage is more interesting. ARM does better at low concurrency across all three workloads. The Graviton3's architectural optimizations seem to help when there's less contention. But once the system is saturated, the bottleneck shifts away from the CPU. Both architectures hit the same wall.

I can't say whether the single-threaded advantage comes from the ARM ISA itself, from Graviton3's specific microarchitecture, or from software optimization. The experiment wasn't designed to isolate that. But as a practical matter, it doesn't matter. If you're running MariaDB on AWS, ARM gives you more for less.

What I'd recommend (with caveats)

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 deploying MariaDB for OLTP on AWS, go with ARM (Graviton3). You get better single-threaded performance, the same multi-threaded performance, and roughly 29% more transactions per dollar. There's no downside I could find.

The only reason to stick with x86_64 is if you have software that genuinely doesn't run on ARM. But MariaDB supports both architectures natively [9], so that's unlikely to be an issue.

What I didn't test

I only tested MariaDB. PostgreSQL or MySQL might behave differently. I used default database configs except for max_connections. Maybe there are tuning parameters that favor one architecture. I only used gp3 storage with modest IOPS. Higher IOPS or provisioned storage might shift the bottleneck.

I didn't look at energy efficiency. ARM instances are supposed to be more power-efficient, but I didn't have access to that data. I only tested in us-east-1. Different regions might have different underlying hardware.

I didn't test reserved instance pricing or long-term sustained workloads. On-demand pricing is the simplest comparison, but real deployments often use reserved or savings plans.

References

[1] A. V. Indukuri, "Cloud-native transformation: Architectural principles and organizational strategies for infrastructure modernization," World J. Adv. Res. Rev., vol. 26, no. 1, pp. 3914–3926, Apr. 2025, doi: 10.30574/wjarr.2025.26.1.1467.

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

[3] "ARM Processor - AWS Graviton Processor - AWS," Amazon Web Services, Inc. Accessed: Aug. 20, 2025. [Online]. Available: https://aws.amazon.com/ec2/graviton/

[4] "5th Gen AMD EPYC Processor Architecture White Paper."

[5] F. Nirwansyah, "Comparison Performance Analysis of HDD, SSD and NVME for OLTP Database Server," J. Syntax Admiration, vol. 5, no. 10, pp. 4379–4388, Oct. 2024, doi: 10.46799/jsa.v5i10.1730.

[6] J. Wang et al., "PolarDB-IMCI: A Cloud-Native HTAP Database System at Alibaba," Proc. ACM Manag. Data, vol. 1, no. 2, pp. 1–25, June 2023, doi: 10.1145/3589785.

[7] Y. Sheng, A. Tomasic, T. Zhang, and A. Pavlo, "Scheduling OLTP Transactions via Machine Learning," May 29, 2019, arXiv: arXiv:1903.02990. doi: 10.48550/arXiv.1903.02990.

[8] R. G. Kula, B. A. Reid, and C. Treude, "Open Source at a Crossroads: The Future of Licensing Driven by Monetization," June 01, 2025, arXiv: arXiv:2503.02817. doi: 10.48550/arXiv.2503.02817.

[9] S. Kaiser, Md. S. Haq, A. S. Tosun, and T. Korkmaz, "Container Technologies for ARM Architecture: A Comprehensive Survey of the State-of-the-Art," IEEE Access, vol. 10, pp. 84853–84881, 2022, doi: 10.1109/ACCESS.2022.3197151.

[10] "EC2 On-Demand Instance Pricing," Amazon Web Services, Inc. Accessed: Aug. 21, 2025. [Online]. Available: https://aws.amazon.com/ec2/pricing/on-demand/