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

31–40 of 68 posts

Re: Benchmarking Postgres 17 vs. 18

#31

Post by jascha_eng »

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?

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.

Re: Benchmarking Postgres 17 vs. 18

#32

Post by lossolo »

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.

You don't need to, just rent dedicated servers, still 20-50x cheaper, problem solved.

Re: Benchmarking Postgres 17 vs. 18

#33

Post by nodesocket »

I'm currently running PostgreSQL in docker containers using bitnami/postgresql:17.6.0-debian-12-r4. As I understand it, Bitnami is no longer supporting or updating their Docker containers. Any recommendations on a upgrade path to PostgreSQL 18 in Docker?

A quick glance of swapping to the official postgres container shows POSTGRESQL_DATABASE is renamed to POSTGRESQL_DB. The other issue is the volume mount path is currently /bitnami/postgresql.

Re: Benchmarking Postgres 17 vs. 18

#34

Post by whizzter »

XCSme wrote: post #24
saxenaabhi wrote: post #15

Earlier quoted context omitted.

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).

You have a call from France, some company called OVH on the line!

Re: Benchmarking Postgres 17 vs. 18

#35

Post by thyristan »

jaza wrote: post #28
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.

If you want your own hardware to be OPEX, just do leasing. Every enterprise hardware seller will make you an offer for that.

Re: Benchmarking Postgres 17 vs. 18

#36

Post by makkes »

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…

Comparing monthly cloud cost with one-time hardware purchasing cost completely dismisses the latter's long-time cost like people, replacement parts, power, housing, accessories. While I do believe you can run your own hardware much cheaper, there's a lot to consider before making the decision.

Re: Benchmarking Postgres 17 vs. 18

#37

Post by makkes »

nodesocket wrote: post #33

I'm currently running PostgreSQL in docker containers using bitnami/postgresql:17.6.0-debian-12-r4. As I understand it, Bitnami is no longer supporting or updating their Docker containers. Any recommendations on a upgrade path to PostgreSQL 18 in Docker? A quick glance of swapping to the official postgres container shows POSTGRESQL_DATABASE is renamed to POSTGRESQL_DB. The other issue is the volume mount path is curr…

Either do a proper upgrade with backup/restore or use `PGDATA`[1] and `pg_upgrade`[2].

[1] https://hub.docker.com/_/postgres#pgdata

[2] https://www.postgresql.org/docs/current/upgrading.html#UPGRA...

Re: Benchmarking Postgres 17 vs. 18

#38

Post by benjiro »

jaza wrote: post #28
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.

> 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.

The idea that managing hardware and software is hard, is silly yet, people (mostly managers it seems ) think its the best solution.

Re: Benchmarking Postgres 17 vs. 18

#39

Post by vbezhenar »

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.

Re: Benchmarking Postgres 17 vs. 18

#40

Post by ozgune »

anarazel wrote: post #4

Afaict nothing in this benchmark will actually use AIO in 18. As of 18 there is aio reads for seq scans, bitmap scans, vacuum, and a few other utility commands. But the queries being run should normally be planned as index range scans. We're hoping to the the work for using AIO for index scans into 19, but it could work end up in 20, it's nontrivial. It's also worth noting that the default for data checksums has chan…

If the benchmark doesn’t use AIO, why the performance difference between PG 17 and 18 in the blog post (sync, worker, and io_uring)?

Is it because remote storage in the cloud always introduces some variance & the benchmark just picks that up?

For reference, anarazel had a presentation at pgconf.eu yesterday about AIO. anarazel mentioned that remote cloud storage always introduced variance making the benchmark results hard to interpret. His solution was to introduce synthetic latency on local NVMes for benchmarks.

Post reply on HN