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

51–60 of 68 posts

Re: Benchmarking Postgres 17 vs. 18

#51

Post by unregistereddev »

hylaride wrote: post #30
layoric wrote: post #26

Earlier quoted context omitted.

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 i…

In some orgs the move to the cloud was driven by accountants. In my org it was driven by lawyers. With GDPR on the horizon and murmurs of other data privacy laws that might (but didn't) require data to be stored in that customer's jurisdiction, we needed to host in additional regions.

We had a couple rather large datacenters, but both were in the US. The only infrastructure we had in the EU was one small server closet. We had no hosting capacity in Brazil, China, etc. Multi-region availability drove us to the cloud - just not in the "high availability" sense of the term.

Re: Benchmarking Postgres 17 vs. 18

#52

Post by manacit »

benjiro wrote: post #38
jaza wrote: post #28

Earlier quoted context omitted.

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.

> You pay for it because you want backups and replication to be somebody else's problem. Or you just use something like CockroachDB, YugabyteDB etc that auto replicate, auto rebalance if a node goes down, and have build in support for backups to and from S3... Or if your a bit more hands on, multigress seems to be closing to completion ( https://github.com/multigres/multigres ) from the guy that make Vitess for Mysql…

I wouldn't say it's closing to completion - it looks like it's in the very early stages development according to their repo. I don't see any evidence they've gotten as far as even running a single query through it.

Even when it's done, it's going to be a lot of work to run. sure, it's not guaranteed to be hard, but if it's not your core business and you're making money, having someone else do it gives you time to focus on what matters.

Re: Benchmarking Postgres 17 vs. 18

#53

Post by jascha_eng »

samlambert wrote: post #42
jascha_eng wrote: post #31

Earlier quoted context omitted.

yeh planetscale loves to flex how fast they are but the main reason they are fast is because they run a full abstraction less than any other cloud provider and this does in fact have trade-offs.

What is wrong with running without lots of abstractions? We are clear about the downsides. The results are clear, you can see the customers love it. We run insane amounts of state safely on ephemeral compute. It's a flex. All I've seen from Timescale people is qqing. Write some code or be quiet.

I'm not criticizing your engineering approach at all. Running everything in one box has its merits as your benchmarks show but it is also just not apples to apples there are other trade-offs and I am just appreciating that the community calls that out.

Also hey this is HN not Twitter I think we can be a bit more civilized. Not a good look imo for a CEO to get that upset over a harmless comment.

Re: Benchmarking Postgres 17 vs. 18

#54

Post by rcrowley »

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?

Yes, a single disk in a VPS or cloud provider has durability concerns. That's why EBS and products like it that pretend to be a single disk are actually several. Instead of relying on multiple block devices, though, we create that redundancy at a higher level by relying on multiple MySQL or Postgres servers for durability, each with a local NVMe drive for performance.

Re: Benchmarking Postgres 17 vs. 18

#55

Post by rcrowley »

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?

RAID isn't the answer, either, for the record. In AWS and GCP, the CPU or RAM blowing up will cost you access to that local NVMe drive, too, no matter how much RAID you throw at it.

Re: Benchmarking Postgres 17 vs. 18

#57

Post by parthdesai »

fourseventy wrote: post #56

I'm literally in the middle of upgrading my prod db to pg18. Its about 6tb, has a few thousand queries per second, should I be considering running in 'worker' mode instead of 'io_uring'?

Why would you migrate your prod db if you aren't sure of all the changes and which config params to use?

Re: Benchmarking Postgres 17 vs. 18

#58

Post by samlambert »

jascha_eng wrote: post #53
samlambert wrote: post #42

Earlier quoted context omitted.

What is wrong with running without lots of abstractions? We are clear about the downsides. The results are clear, you can see the customers love it. We run insane amounts of state safely on ephemeral compute. It's a flex. All I've seen from Timescale people is qqing. Write some code or be quiet.

I'm not criticizing your engineering approach at all. Running everything in one box has its merits as your benchmarks show but it is also just not apples to apples there are other trade-offs and I am just appreciating that the community calls that out. Also hey this is HN not Twitter I think we can be a bit more civilized. Not a good look imo for a CEO to get that upset over a harmless comment.

We run 3 nodes not 1. Your comment is not in isolation we get constant shade from Timescale people when we don't even think about you.

Re: Benchmarking Postgres 17 vs. 18

#59

Post by jackdoe »

vbezhenar wrote: post #39
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…

Most clouds I've used allow you to create VM with local disk, and that might be cheaper that network disk.

This is the 500$ per month option they are describing in the post, the magnificent 300,000 IOPS, the network disk is 1500$ for 16000 IOPS

not to mention then you have all the issues people are discussing managing your own backups, snapshots and replication and etc

Post reply on HN