. -->

PostgresBench: Measuring the impact of High Availability on Managed Postgres performance | ClickHouse<br>Skip to content

Open searchOpen region selectorEnglish<br>Japanese

48.8kSign inGet Started

->Scroll to top<br>BackBlog<br>Engineering<br>Copy pageCopied!More actionsView as Markdown Open this page in Markdown<br>Open in ChatGPT Ask questions about this page<br>Open in Claude Ask questions about this page<br>Open in v0 Ask questions about this page

PostgresBench: Measuring the impact of High Availability on Managed Postgres performance

Lionel Palacin, Sai Srirampur and Andrey Chudnovskiy<br>Jul 21, 2026 · 9 minutes read

A few months ago, we released PostgresBench, an open source benchmark that compares managed Postgres performance across vendors with a transparent, reproducible methodology. It was well received by the Postgres community, and the most common piece of feedback we heard was why we hadn't benchmarked any high availability configurations. Today, we've addressed that, and we're sharing results for HA configurations across those same vendors.

One important clarification: this isn't a complete high-availability comparison across vendors. It measures only the performance cost of achieving comparable levels of availability and data durability across various Postgres managed services.

Get started with ClickHouse Managed Postgres today<br>Interested in seeing how ClickHouse Managed Postgres works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.<br>Sign up<br>HA Setup across Postgres services #

Managed Postgres services typically use two different architectures to provide high availability.

Shared-nothing services (ClickHouse Managed Postgres, AWS RDS, and Crunchy Bridge) use isolated compute and single-tenant storage deployments for each customer instance, and rely on native PostgreSQL replication, with one or more physical streaming standbys and automatic failover if the primary becomes unavailable.

Shared-storage services (AWS Aurora and Neon, both forks of Postgres) separate compute and storage, achieving durability by writing multiple copies of the WAL to a replicated storage layer on the commit path, and replacing failed compute nodes without relying on traditional streaming replicas.

For this comparison, we've defined high availability as the system's claim to recover after a primary failure within 2 minutes and zero data loss guarantees. We selected the closest comparable HA configuration offered by each managed service while keeping the comparison as fair as possible. The sections below describe the configuration we benchmarked for each vendor.

We matched the primary compute resources (CPU and RAM) as closely as possible across all vendors to ensure a fair comparison. For the shared-storage services this is not the full picture: hardware profiles and redundancy configuration on the storage backends are not publicly disclosed, though they contribute to system performance and reliability.

ClickHouse Managed Postgres #

ClickHouse Managed Postgres is a local NVMe-backed Postgres service optimized for high-performance OLTP workloads. Because local NVMe storage is ephemeral in the event of compute failures, the service offers multiple high-availability (HA) configurations with different durability levels.

The single-standby configuration uses asynchronous replication and is ideal for workloads that can tolerate a small recovery point objective (RPO) i.e. accepting a few milli-seconds of lost transactions. The two-standby configuration uses synchronous quorum replication to provide zero data loss (RPO = 0). Because all durability and high availability come from PostgreSQL replication and WAL upload rather than replicated disks, zero data loss with cross-AZ high availability today requires this quorum of 3 instances; we're working on a similar durability guarantee without the 3rd instance.

This was an intentional design choice to provide customers with the control and flexibility to choose their preferred HA configuration (0, 1, or 2 standbys) based on the mission-criticality of their workload. Both configurations are designed for fast failover, with hot standbys that minimize recovery time (RTO) when the primary becomes unavailable.

Crunchy Bridge #

Crunchy Bridge (Snowflake Postgres) provide high availability using a single physical streaming standby replica. By default, replication is asynchronous. We were unable to configure synchronous replication (tweaking synchronous_commit) and did not find an option to guarantee a zero RPO. If we overlooked a supported configuration or setting, please let us know, we're happy to update this post accordingly.

AWS RDS Postgres #

AWS RDS (and Crunchy Bridge) rely on replicated managed disks for in-AZ durability, and hot standby PostgreSQL instances for high availability and cross-AZ durability. RDS supports one or two standbys, and both options always replicate synchronously, so there's no data loss on failover. We tested...