We have gone 100% ARM: double the capacity, three quarters off the bill

At Badger Commerce, scaling smarter beats scaling harder. This year we made a decisive move: our infrastructure platform is now 100% ARM-based.

The results have surpassed what we expected going in.

Why we migrated#

We had run on mixed x86 and ARM-capable infrastructure for a while. Familiar and reliable, but increasingly expensive and increasingly fiddly to manage.

As the product, the traffic and our internal workloads kept growing, the choice in front of us was to add more machines rather than get more out of each one. Meanwhile the industry was moving: Google's published figures for its Axion ARM processors claim up to 65% better price-performance and up to 60% better energy efficiency than comparable x86 instances. Those are Google's numbers for Google's silicon, not ours — but they were enough to make the question worth asking properly.

Could Badger Commerce get more capacity, lower cost and simpler operations by going all-in on ARM?

The answer was yes.

The numbers#

The cost reduction came from better performance per watt, right-sizing instances properly during the move, and simply having fewer idle resources afterwards. The capacity gain is the same story from the other side: workloads that previously needed a broad horizontal spread now run denser and faster on ARM nodes.

Two things we did not put a number on, because they are structural rather than measurable:

Environment consolidation. Higher density per node let us retire several duplicate and shadow environments, which shrank the deployment matrix.

A simpler architecture. Fewer scaling edges, fewer instance types, fewer special cases. That means fewer surprises and fewer bugs, and it is the part of this we expect to keep paying back.

How we did it#

1. 1

   Benchmark, then pilot

   We ran identical workloads on x86 and ARM and measured performance, cost, memory behaviour and I/O. ARM came out clearly ahead for our workload patterns — which is not a foregone conclusion, and is exactly why you measure your own workloads rather than someone else's.

2. 2

   Refactor the build and test pipelines

   This is the part people underestimate. Changing architecture means changing CI/CD, build flags and test suites. We added automated validation to catch architecture-specific failures early, because the alternative is finding them in production.

3. 3

   Re-plan capacity from scratch

   With better performance per core and per socket, the old node-sizing model was wrong. We moved to fewer, larger ARM instances where it made sense and retired a long tail of small legacy hosts.

4. 4

   Rationalise the environments

   The extra capacity per node meant dev, test, QA and staging clusters could be consolidated, duplication removed, and the older x86 clusters retired entirely.

5. 5

   Reinvest the savings

   The savings went into product work, reliability engineering, monitoring and autoscaling, rather than into a spreadsheet. That is what makes a migration like this fund the next one.

What it means for the stores we run#

You will never see "we now run on ARM" on a checkout page. You will notice the consequences:

• Faster response times, and headroom for growth. We doubled capacity without doubling cost, so peak trading has more room in it than it did.
• Fewer maintenance windows and fewer infrastructure surprises, because there is substantially less infrastructure to surprise us.
• A lower cost base, which is what lets us keep pricing competitive and keep investing in features and reliability rather than in servers.
• A smaller environmental footprint — better power utilisation and far fewer idle machines.

What is next#

This migration is a foundation, not a finish line.

We are continuing to tune workloads for ARM-specific behaviour, including vector extensions and cache characteristics we have not yet exploited. We are watching real-world telemetry to push performance further. And we will look at hybrid multi-architecture strategies where a new workload genuinely needs something else — GPU work, for instance — with ARM as the core rather than as one option among several.

Why any of this matters to a retailer#

If you are evaluating an ecommerce platform, you are not only buying software. You are buying reliability, performance and headroom.

Great commerce software should not require an enormous infrastructure budget or a zoo of specialised hosts. It should quietly work: scale up when it needs to, stay fast, stay efficient. Cutting cost, adding capacity and removing complexity in one move is how you get there, and it is what this migration bought us.

Want to talk about how an ARM-first architecture translates into something real for your store? Drop us a line — we are always happy to talk about the numbers.