Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benchmarking Postgres 17 vs. 18

planetscale.com

Post reply on HN
Print view View original

21–30 of 68 posts

Re: Benchmarking Postgres 17 vs. 18

#21

Post by jackdoe »

Hrun0 wrote: post #20
jackdoe wrote: post #18

> IOPS: 3,000 > IOPS: 300,000 for 551$ per month the cloud is ridiculous. just for reference with 4 consumer nvmes and raid10 and pciex16 you can easily do 3m IOPS for one time cost of like 1000$ in my current job we constantly have to rethink db queries/design because of cloud IOPS, and of course not having control over RDS page cache and numa. every time I am woken up at night because a seemingly normal query all o…

But now you need someone to deal with the hardware.

oh no! this is proven to be impossible, no man can tell a computer what to do

lspci is only written in the old alchemy books, in the whispers of the thrice great Hermes.

PS: I have personally put down actual fires in a datacenter, and I prefer it to this 3000 IOPS crap.

Re: Benchmarking Postgres 17 vs. 18

#22

Post by hans_castorp »

rastignack wrote: post #10

Is there now a way to avoid double buffering and use direct IO in postgresql ? Has anybody seriously benchmarked this ? I don’t think io uring would make a difference with this setting but I’m curious, as it’s the default for oracle and sybase.

Direct I/O is being worked on, but is not yet available.

See e.g. here: https://www.cybertec-postgresql.com/en/postgresql-18-and-bey...

Re: Benchmarking Postgres 17 vs. 18

#24

Post by XCSme »

saxenaabhi wrote: post #15
cheema33 wrote: post #13

The primary lesson I learned here was this: If you care about performance, don't use network storage. If you are using local nvme disk, then it does not matter if you are using Postgres 17 or 18. Performance is about the same. And significantly faster than network storage.

But ephemeral and non-redundant. Am I correct in that using local disk on any VPS has durability concerns?

On some providers (e.g. Hetzner), the dedicated servers come by default with 2x RAID 1 disks, so it's a lot less likely to fail (unless the datacenter burns down).

Re: Benchmarking Postgres 17 vs. 18

#26

Post by layoric »

Hrun0 wrote: post #20
jackdoe wrote: post #18

> IOPS: 3,000 > IOPS: 300,000 for 551$ per month the cloud is ridiculous. just for reference with 4 consumer nvmes and raid10 and pciex16 you can easily do 3m IOPS for one time cost of like 1000$ in my current job we constantly have to rethink db queries/design because of cloud IOPS, and of course not having control over RDS page cache and numa. every time I am woken up at night because a seemingly normal query all o…

But now you need someone to deal with the hardware.

Working at IT places in the late 2000s, it was still pretty common place for there to be a server rooms. Even for a large org with multiple sites 100s of kms a part, you could manage it with a pretty small team. And it is a lot easier to build resilient applications now than it was back then from what I remember.

Cloud costs are getting large enough that I know I’ve got one foot out the door and a long term plan to move back to having our own servers and spend the money we save on people. I can only see cloud getting even more expensive, not less.

Re: Benchmarking Postgres 17 vs. 18

#28

Post by jaza »

jackdoe wrote: post #18

> IOPS: 3,000 > IOPS: 300,000 for 551$ per month the cloud is ridiculous. just for reference with 4 consumer nvmes and raid10 and pciex16 you can easily do 3m IOPS for one time cost of like 1000$ in my current job we constantly have to rethink db queries/design because of cloud IOPS, and of course not having control over RDS page cache and numa. every time I am woken up at night because a seemingly normal query all o…

You don't pay for RDS because you care about IOPS. You pay for it because you want backups and replication to be somebody else's problem. And because you (by which I mean probably the MBA management above you, rather than you yourself) care about it being an opex rather than capex cost, a lot more than you care about how much the cost is. And because ISO audit boxes get ticked.

Re: Benchmarking Postgres 17 vs. 18

#29

Post by ralusek »

layoric wrote: post #26
Hrun0 wrote: post #20

Earlier quoted context omitted.

But now you need someone to deal with the hardware.

Working at IT places in the late 2000s, it was still pretty common place for there to be a server rooms. Even for a large org with multiple sites 100s of kms a part, you could manage it with a pretty small team. And it is a lot easier to build resilient applications now than it was back then from what I remember. Cloud costs are getting large enough that I know I’ve got one foot out the door and a long term plan to m…

And it’ll be so good and cheap that you’ll figure “hell, I could sell our excess compute resources for a fraction of AWS.” And then I’ll buy them, you’ll be the new cloud. And then more people will, and eventually this server infrastructure business will dwarf your actual business. And then some person in 10 years will complain about your IOPS pricing, and start their own server room.

Re: Benchmarking Postgres 17 vs. 18

#30

Post by hylaride »

layoric wrote: post #26
Hrun0 wrote: post #20

Earlier quoted context omitted.

But now you need someone to deal with the hardware.

Working at IT places in the late 2000s, it was still pretty common place for there to be a server rooms. Even for a large org with multiple sites 100s of kms a part, you could manage it with a pretty small team. And it is a lot easier to build resilient applications now than it was back then from what I remember. Cloud costs are getting large enough that I know I’ve got one foot out the door and a long term plan to m…

There is currently a bit of an early shift back to physical infra. Some of this is driven by costs(1), some by geopolitical concerns, and some by performance. However, dealing with physical equipment does introduce a different set (old fashioned, but somewhat atrophied) set of skills and costs that companies need to deal with.

(1) It is shocking how much of a move to the cloud was driven by accountants wanting opex instead of capex, but are now concerned with actual cashflow and are thinking of going back. The cloud is really good at serving web content and storing gobs of data, but once you start wanting to crunch numbers or move that data, it gets expensive fast.

Post reply on HN