Good point! I kept the configuration of the Postgres pretty close to the defaults, and it would be interesting to compare it with the same default Aurora Postgres.
And it should be easy to add - I'll check it, thanks!
Yes! This was my initial dilemma - whether to test RDS or self-hosted Postgres on EC2. I decided to start with EC2 to be a bit more "pure", and remove cost overhead of RDS.
But support for RDS is my next candidate for development. Plus, comparison would also be interesting.
Would be interesting to see huge pages and io2 impact.
I did a smaller version on Azure and disk latency had a massive impact much more so than max IOPs (although their crappy storage offering needed like 64-128 iodepth to get advertised iops).
Results seem mostly in line with expectations. Iirc vcpu is threads so on arm64 you get 4 smt1 cores vs Intel/AMD you get 2 smt2 cores.
Good points, thanks. On huge pages: this is also about RDS vs self-managed EC2 Postgres. RDS effectively has "on" by default, but default self-managed (that I benchmarked) is "try" which is effectively "off". I'll update the methodology page to cover that, and, yeah, it makes sense to cover that separately.
io2 is on my future-work list. And agree, I have the same feelings about IOPS.
I'd be very curious to see you add the Optimized Reads instance types, e.g. r8gd or m8gd, to your benchmark. They add a local NVMe-based SSD block storage that serves as a cache in front of the network-based disks among other use cases. They have been a huge win for us for a read-heavy workload where the dataset is significantly larger than memory.
Edit: Apologies, on a closer read, I realize you were not testing RDS but managing Postgres on EC2 directly.
I think we have a lot of DBs specialised for heavy write, like anything with LSM-tree in their base.
My vision is that there will be more movement in this direction, but still, we need first to understand limits of "easy to work with" databases like Postgres. It's easy to underestimate what Postgres can do.
And only when it's not enough, move to something LSM-tree-based.
Small badges will be helpful, though. I added hovers in some places, like for latency numbers, but I think more visible badges will work better, thanks!
ballislife30 | a day ago
[OP] anivan_ | a day ago
And it should be easy to add - I'll check it, thanks!
toredash | a day ago
[OP] anivan_ | a day ago
But support for RDS is my next candidate for development. Plus, comparison would also be interesting.
nijave | a day ago
I did a smaller version on Azure and disk latency had a massive impact much more so than max IOPs (although their crappy storage offering needed like 64-128 iodepth to get advertised iops).
Results seem mostly in line with expectations. Iirc vcpu is threads so on arm64 you get 4 smt1 cores vs Intel/AMD you get 2 smt2 cores.
[OP] anivan_ | a day ago
io2 is on my future-work list. And agree, I have the same feelings about IOPS.
Rafuino | 23 hours ago
crudgen | a day ago
[OP] anivan_ | a day ago
It would also be interesting to have cross-provider comparison. I think it's doable. Thanks!
mattlong | a day ago
Edit: Apologies, on a closer read, I realize you were not testing RDS but managing Postgres on EC2 directly.
[OP] anivan_ | a day ago
Thanks for highlighting this!
Rafuino | 23 hours ago
[OP] anivan_ | 22 hours ago
handfuloflight | 19 hours ago
[OP] anivan_ | 4 hours ago
My vision is that there will be more movement in this direction, but still, we need first to understand limits of "easy to work with" databases like Postgres. It's easy to underestimate what Postgres can do.
And only when it's not enough, move to something LSM-tree-based.
TurdF3rguson | 18 hours ago
[OP] anivan_ | 4 hours ago
Small badges will be helpful, though. I added hovers in some places, like for latency numbers, but I think more visible badges will work better, thanks!
sysguru2046 | 17 hours ago
[OP] anivan_ | 4 hours ago
Especially, cost-efficiency. I'll think how to put it, thanks :)