Google Cloud SQL: x86 N2 vs ARM C4A

Published: Nov 08, 2025 on dev.to by Dimitrios Kechagias

#googlcloud #gcp #mysql #database

The recent upgrade of our production Cloud SQL databases to Enterprise Plus required an in-place process to minimize downtime for our 2TB instance. This meant that we couldn't explore the new C4A ARM option offered under Enterprise Plus offers, as it currently does not support in-place upgrades (I am told Google is working on it though).

Given how impressed I was when testing Google Axion-powered C4A GCP VMs, I thought I should explore the C4A Cloud SQL performance for initial use in our test environment, with an eye toward potential future production use.

• Enterprise Plus: C4A vs N2
• Import Performance
• Latency
• SELECTs
  • Very fast (<10ms)
  • Fast (<200ms)
  • Slow (>200ms)
  • Very Slow (>20s)
• UPDATEs
• INSERTs
• DELETEs
• Addendum: Enterprise N4
• Conclusions

Enterprise Plus: C4A vs N2

In my testing, the 4th gen C4A cores, based on Google's own Axion ARM CPU, prove both faster than the Intel Cascade Lake / Ice Lake N2 CPUs and they offer a full physical core per vCPU instead of just a Hyper-Thread. This will surely have some throughput advantage.

Additionally, C4A as a 4th gen instance has access to the newer "Hyperdisk" storage with fully configurable IOPS and throughput (instead of having them scaled depending on size). This flexibility comes with a slightly higher cost, as shown in the comparison below:

The 600GB storage size matches the sample database used. For price parity, I’ve included an N1 Enterprise instance with nearly twice the cores. The C4A was tested in three different Hyperdisk configurations:

• low: for price-parity, but close to minimum possible Hyperdisk specs, so not recommended.
• mid: ~10% higher cost, more realistic balance.
• high: ~30% price premium, used to test scaling with high IOPS.

Benchmarks were performed using my MCE::Benchmark
Perl module to run randomized queries with varying thread counts, simulating different load levels.

A 32x C4D VM in the same region and zone as the MySQL 8.0 Cloud SQL instances handled the benchmarking, connecting via Perl DBI/DBD::mysql.

Import Performance

The first task was importing the ~600GB MySQL database from a GCP bucket:

Even the C4A-mid shows over 35% advantage vs the N2 and twice that over the N1 instance. This is a significant difference, cutting hours from the import of such a large database.

Latency

In my previous post, I briefly mentioned the latency differences between N1 and N2. Here’s a closer look at "SELECT 1" response times across 1–64 threads:

Impressively, the C4A delivers an average round-trip time of just 0.1ms, making the N2’s 0.25ms seem sluggish by comparison. The N1, with a much slower 1.5ms latency, processes far fewer requests per second and thus doesn’t experience contention even at 64 threads.

SELECTs

Randomized SELECTs based on real workloads were grouped into four categories by execution time.

Very fast (<10ms)

For small in-memory queries, let's see the max throughput at various concurrency levels:

Having twice the hardware cores vs N2, the C4A saturates slower and maxes out at over twice the throughput. We can also see the same data as a query response time:

It's clear that under load (8+ threads) C4A does not slow down nearly as fast as N2.

Fast (<200ms)

Similar behaviour, also in-memory queries, N2 saturates here at 4 threads, C4A increases throughput past 8:

Slow (>200ms)

For more complex queries involving larger joins, the C4A’s advantage narrows. At 64-thread concurrency, performance collapses as the workload becomes I/O bound:

Interestingly, the N2’s storage (with higher theoretical IOPS) outperforms the mid-tier Hyperdisk in these extreme scenarios. This does not imply that maximum Hyperdisk specs are required - if your MySQL workload depends that heavily on disk I/O, you are probably doing something wrong.

Very Slow (>20s)

For very slow reporting queries, once warmed up, C4A maintains a 25–30% lead over N2.

For very slow report queries, after the database is warmed up, we can see a 25-30% advantage of C4A over N2:

It may also be interesting to see a "warmup" run on a cold database, where data will be read from the disk:

As we saw before, in extreme disk access cases such as this cold start, N2’s higher base IOPS outperform the mid-tier Hyperdisk configuration.

UPDATEs

In a mix of updates, including compound indexes, which means both CPU and disk access are involved, the N2 seemed to keep up better with the C4A:

The low-spec Hyperdisk configuration quickly becomes a bottleneck; at least the mid level is needed for balanced performance. N1 trails significantly once again.

INSERTs

A mix of complex inserts, with the disk access playing a bigger role:

It's quite interesting to see how throughput increases with load, until there is some sort of storage-related bottleneck hit. It happens quickly with the low Hyperdisk, then with the mid Hyperdisk, while the high Hyperdisk config manages to keep up farther than the N1/N2 solutions.

DELETEs

I tested 2 types of mass DELETE statements - one with a LIMIT x loop, the other with passing ids as bind variables:

Two types of bulk DELETE operations were tested: one using a LIMIT x loop and another using bound ID variables (single-threaded for consistency).

There is a near 20% advantage for C4A, as long as the IOPS of the Hyperdisk are not set too low.

Addendum: Enterprise N4

I performed the above tests over the summer. In the meantime Google released Enterprise instances based on their 4th Gen x86 architecture (Intel Emerald Rapids, Hyperdisks), so I thought I'd add a quick comparison between the N4 Enterprise and N2 Enterprise plus for completeness. For about the same price you can get 50% more N4 cores than N2, keeping the Hyperdisk IOPS at the mid levels we used in the previous tests. Similar to the C4A, you cannot currently convert an N1 or N2 instance to an N4 due to the different storage.

Here are the results of the most common types of in-memory SELECTs:

As expected, the N4 cores are a bit faster, and you can get more for the price so give you a significantly higher throughput, making them a better value (it would mean forgoing the extra Enterprise Plus benefits of course).

I tried some tests with DELETEs and some very deep SELECTs with CREs, which seemed to variously go one way or the other between the two types, but I couldn’t achieve consistent enough results in time to include them, so I will need to come back to this, along with an N4 to C4A comparison.

Conclusions

The takeaways as I see them:

• For maximum in-memory query performance & throughput, you should go to C4A. It will cost a bit more as you should pair it with a Hyperdisk that has reasonable specs.
• In the possibly less common case where disk I/O is the main concern, N2 may be your budget solution with the disk I/O performing on par or better than a mid spec Hyperdisk at a lower price. However, for I/O performance regardless of budget, the Hyperdisk of a C4A can be configured to be much faster at an additional cost.
• The addition of the N4 option for Enterprise with better performance makes the N2 less attractive if you don't mind losing the Enterprise Plus features. The C4A will still have an edge in performance, due to slightly faster cores (and full core/vCPU), but I will have to follow up with some benchmarks on it.
• Overall, I would be choosing between N4 & C4A for new deployments. Existing non-Hyperdisk instances are not currently directly upgradeable to them, so it is not as easy to take advantage of them in existing deployments.

To see the comments or leave new ones, visit original article on DEV.to.