Earlier quoted context omitted.
Lack of protocol compression is painful with postgres
Untrue since the introduction of zstd support in PostgreSQL 15.
Are you sure?
PostgresBench: A Reproducible Benchmark for Postgres Services
21–25 of 25 posts
Re: PostgresBench: A Reproducible Benchmark for Postgres Services
#22Earlier quoted context omitted.
Ack on most points i.e. duration, scale factor (data size) and pricing. We will try incorporating these in the next iterations. In regards to HA, partly agreed. We are working on adding HA setup as we speak, should be released soon. However note that the local NVMe setup does have backups and WAL-archival to S3, which provides data-durability with RPO of 10s of seconds. Even with HA setup I expect performance differe…
> note that the local NVMe setup does have backups and WAL-archival to S3, which provides data-durability with RPO of 10s of seconds. That's good, it provides a reasonable level of RPO, although I prefer just 0. But with this the RTO (or, equivalently, the downtime) is potentially quite large. > Even with HA setup I expect performance difference to be similar across systems (may be slightly lesser) I have done some b…
Ack, your insight is very interesting.
Back at Citus/Microsoft, we typically saw around a 30% performance drop with synchronous replication on EBS-backed Postgres. I’d expect something in that ballpark for RDS and Crunchy as well. For NVMe-backed Postgres, we haven’t yet measured the impact of quorum-based replication, and it’s certainly possible the overhead ends up being higher than 30%.
That said, the single-node margins are already quite substantial, over 2× in all cases and up to 5× versus RDS in our benchmarks. Even with a meaningful HA penalty, NVMe-backed setups could still remain very compelling from a performance perspective. We’ve just started running HA benchmarks, so stay tuned.
Side note local NVMe backed Postgres is for perf is not new - many enterprise companies like Datadog and Instacart run their performance critical services on them, though self-managed.
In regard to RTO for single-node setups, it wouldn’t be great (at least minutes) in most systems, since recovery still needs to happen from backups.
Overall, very useful feedback. Thanks again for chiming in!
Re: PostgresBench: A Reproducible Benchmark for Postgres Services
#23I'm curious to know how PlanetScale Postgres would fare.
We have seen them benchmarking us before. I assume we won because they didn't include
It could be the other way round too. ;) We just limited the number of Postgres providers in the first batch. May add you in the next and might ping you before sharing it in public, just to make you sure you are aligned and like them.
Re: PostgresBench: A Reproducible Benchmark for Postgres Services
#24While it’s important to focus on the backend itself, why don’t anyone focus on the clients which talk to the databases, it is there most of an applications problem starts also in regards to performance.
Lack of protocol compression is painful with postgres
Sure, but that is rarely the biggest issues facing a client: top contenders are always queue, pool and decoding. And obviously lack of SQL being a first class in most languages.
Re: PostgresBench: A Reproducible Benchmark for Postgres Services
#25My 2 cents: > Each run lasts 10 minutes, long enough to move past warmup and capture stable throughput But short enough not to show the effect of checkpoints (which is quite noticeable). It's not representing a realistic workload. I'd use at the very least 30mins with checkpoint_timeout=5mins so you get at least 6 checkpoint cycles. > We report average TPS, average latency, P95 latency, and P99 latency Unless I'm mis…
And:
> The instance was assigned a public IP
I think that without a private link, the managed services that run in different accounts (Neon, Crunchy, Clickhouse if not BYOL) may be in a different data center than the client's. And this is just default pgbench where most of the time is spent on client-server roundtrips