This can make a significant performance difference, and at least for the RPM-based official Postgres packages this is a problem: https://www.postgresql.org/message-id/CACN56%2BP1astF5zvocrT...
I was running Postgres on a 2-core/2GB ARMv8 scaleway instance and had to migrate to AWS T2 micro (1-core/1GB)x86 when scaleway pulled the plug on ARM servers.
I expected performance decrease due to obvious reduction in HW specs, but on the contrary the application is much snappier. I don't have PG bench figures, but I can clearly notice performance improvements (discounting the network variables).
To put this into Workload per Dollar. Graviton 2 on AWS is roughly 50% to 60% cheaper. Now not every workload will benefits, there are many CPU intensive workload especially those benefits from SIMD won't work as well on current Graviton 2. But there are enough workloads especially those dealing with Web Stack has shown huge cost savings.
Hopefully this add perspective when people are thinking Intel's Server Platform is still relatively safe. I wrote something about it here .
They said it was happening because of load, which is a falsehood, since I'm talking about a machine coming up after a reboot.
There is something broken on ARM on AWS there. And even after multiple tickets, they aren't able to fix it
You've likely given up much more than 10-25% by using AWS in the first place (note to the false dichotomist: this doesn't mean owning your own servers). And paid a premium for the privilege.
If you're CPU-bound, get a E-2288G (or whatever the commodity chip that maximized price/$$ is right now) and set mitigations=off.
But if price or performance or user privacy is a concern, none.
I'm a big believe in dedicated hosting. There's tens of thousands of options. Not affiliated with any, but in the past/present what I have/am using and would recommend: webnx.com, reliablesite.net, hivelocity.com, hetzner.com, ovh.com (and their other brands), leaseweb.com we're currently considering phoenixnap.com for a warm-standby DR site (but no experience with them yet). Also, Softlayer pre-IBM acquisition, but that's just sour grapes.
They have a good reputation for stability too, unlike (say) Scaleway. ;)
I think they end up close to same price/performance as the Intel offerings as well once you invoke the compiler optimiser. The main benefit is better core scalability and lower energy usage which may work out as a net gain for database workloads.
As always it’s best to measure these things yourself with your expected workload.
But you're right in that in the end it all depends on your workload.
Edit: T4g's are available on EC2.
Waiting for the t4 instances.
Are there other factors that could explain the large performance gap?
graviton2 are real cores while amd/intel is SMT vCPU's. So 2x real cores difference.
Packet whatever their name is now (equinox metal or something) is a competitor but only against the bare metal instances, no cheap tiny VM product unfortunately.
Huawei Cloud... has weird region restrictions for their arm offering but it exists??
Additionally the ARM version only had one disk vs two for x86.
I also feel like there is more headroom for optimization now that ARM is more visible as a server class target in the non-postgresql toolchains.
Not every workload are behind a loadblancer, so single core / MT / single instance performance can be important.
I'm genuinely excited to get my hands on these systems, and see how well they can do. There has been so many promises of a future based on ARM powered servers, and claims about their advantages, and it finally seems like it's within reach from a performance perspective. Whether they'll meet the other expectations, I couldn't guess, but this surely has to be concerning for Intel.
Maybe the M1 success will cause some players to re-think things, but for now, there doesn't seem to be an easier path for competitive high-end ARM servers apart from what Amazon is doing.
The benefit of N2D is that it's still x86, so your existing binaries should work.
Disclosure: I work at Google.
The api developers will be using will be staying the same. It’ll be transparent.
For a staging server, I would. Just to be as close to prod as possible and actually have the same environment and packages to debug against if needed.
I promise you, you’ll know with plenty of time to spare before you’re going to hit the current 64-core limit of Graviton before you need to decide if you can fit into a 128 vCPU (which I believe are hyper threads not cores) x86_64 instance.