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

61–68 of 68 posts

Re: Benchmarking Postgres 17 vs. 18

#61

Post by mbesto »

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…

> I can only see cloud getting even more expensive, not less.

When you have three major hyperscalers competing for your dollars this is basically not true and not how markets work...unless they start colluding on prices.

We've already seen reduction in prices of web services costs across the three major providers due to this competitive nature.

Re: Benchmarking Postgres 17 vs. 18

#62

Post by pas »

sgarland wrote: post #47
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?

Yes, it’s the ephemerality that’s the biggest issue. Enterprise-grade SSDs are quite reliable, and typically have PLP so even in the event of a sudden power loss, any queued writes that the drive has accepted - and thus ack’d the fsync() - will be written. Presumably you’d be running some kind of redundancy, likely some flavor of RAID or zRAID (assuming purely local storage here, not a distributed system like Ceph, n…

... sounds like a trivial job for bare metal instances

and that EC2 local NVMe encryption keys are ephemeral is nice against leaks, but not a necessity for other clouds (and not great for resumability, which can really downgrade business continuity scores), and I expect for all the money they ask for it, to be able to keep it relatively secure even across reboots

Re: Benchmarking Postgres 17 vs. 18

#63

Post by BonoboIO »

pas wrote: post #62
sgarland wrote: post #47

Earlier quoted context omitted.

Yes, it’s the ephemerality that’s the biggest issue. Enterprise-grade SSDs are quite reliable, and typically have PLP so even in the event of a sudden power loss, any queued writes that the drive has accepted - and thus ack’d the fsync() - will be written. Presumably you’d be running some kind of redundancy, likely some flavor of RAID or zRAID (assuming purely local storage here, not a distributed system like Ceph, n…

... sounds like a trivial job for bare metal instances and that EC2 local NVMe encryption keys are ephemeral is nice against leaks, but not a necessity for other clouds (and not great for resumability, which can really downgrade business continuity scores), and I expect for all the money they ask for it, to be able to keep it relatively secure even across reboots

Or even a bare metal simple server that just does databases with redundant nvme ssd

Re: Benchmarking Postgres 17 vs. 18

#64

Post by BonoboIO »

whizzter wrote: post #34
XCSme wrote: post #24

Earlier quoted context omitted.

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!

And your backup goes up in flames too.

I would never ever trust OVH with any important data or servers, I mean we saw how they secured their datacenters where it took 3h to cut the power while the datacenter was burning.

Re: Benchmarking Postgres 17 vs. 18

#65

Post by spprashant »

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'?

For upgrades which have enough risks as it is, I would keep the number of variables low. Once upgraded and stable, you can replicate to a secondary instance with io_method switched and test on it before switching over.

Re: Benchmarking Postgres 17 vs. 18

#66

Post by DicIfTEx »

anarazel wrote: post #50
DicIfTEx wrote: post #12

I was expecting `pg_dumpall` to get the `--format` option in v18,[0] but at the moment the docs say it's still only available in the development branch.[1] Is anyone familiar with Postgres development able to give an update on the state of the feature? Is it planned for a future (18 or 19) release? [0]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... [1]: https://www.postgresql.org/docs/devel/app-pgdu…

The docs for 18 also show it, where do you get from that it's not available for 18?

Ah my mistake, I linked to the docs for `pg_dump` (which has long had the `format` option) rather than `pg_dumpall` (which lacks it).

Before Postgres 18 was released, the docs listed `format` as an option for `pg_dumpall` in the upcoming version 18 (e.g. Wayback Machine from Jun 2025 https://web.archive.org/web/20250624230110/https://www.postg... ). The relevant commit is from Apr 2025 (see link #0 in my original comment). But now all mention has been scrubbed, even from the Devel branch docs.

Re: Benchmarking Postgres 17 vs. 18

#67

Post by anarazel »

DicIfTEx wrote: post #66
anarazel wrote: post #50

Earlier quoted context omitted.

The docs for 18 also show it, where do you get from that it's not available for 18?

Ah my mistake, I linked to the docs for `pg_dump` (which has long had the `format` option) rather than `pg_dumpall` (which lacks it). Before Postgres 18 was released, the docs listed `format` as an option for `pg_dumpall` in the upcoming version 18 (e.g. Wayback Machine from Jun 2025 https://web.archive.org/web/20250624230110/https://www.postg... ). The relevant commit is from Apr 2025 (see link #0 in my original com…

It got reverted for now: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

Re: Benchmarking Postgres 17 vs. 18

#68

Post by saxenaabhi »

fabian2k wrote: post #19
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?

Databases like Postgres have well established ways to handle that. And if you're setting up the DB yourself, you absolutely need to do backups anyway. And a replica on a different server.

Backups don't alleviate durability concerns. Read replicas(async) neither.

I think only way it could work was if I implemented sync replication like planetscale, but that arduous.

Post reply on HN