That gp3 volume is extremely slow compared to a $100 NVMe drive. If each txn does a heap update, index update, wal write, and heap read, that's 4 IOs per txn right there (well, not for sequential IDs because you don't need to flush heap/index on every update). The volume gets 16k IOPS max, so that 2600-3400 txn/s is somewhat close to its capabilities assuming multiple IOs per txn. It's a little hard to find info, but latency of a gp3 volume is approximately 1 ms? That's going to limit you on WAL writes since they're synchronous. An NVMe drive that does say 20k read and 50k write IOPS at qd1 has 50 us read / 20 us write latency. A database should be more of a qd32 workload, so hundreds of thousands to millions of IOPS.

It's a single core, so no parallelism in the db itself. There's a fraction of the RAM my phone has, so that slow IO is more pronounced.

The basic implications of different keys and detailed look at the cache internals are valid and interesting, but the hardware is nothing like a server you'd want to run a database on, so the benchmark isn't very interesting. An iPhone is probably beefier in every way.

>c7a servers have dedicated CPUs

I can't see any proof of that, sources?

They talk about vCPU here:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/compute-...

Do you mean for example c6g.metal? For c7a there are also "metal" instances available, but they don't mention that:

https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html...

Only c7a.48xlarge or (ideally) its c7a-48.metal equivalent instance. Otherwise you’ve got a CPU-stealing neighbor.