. -->

Benchmarking NVMe-backed Managed Postgres: PlanetScale and ClickHouse | ClickHouse<br>Skip to content

Open searchOpen region selectorEnglish<br>Japanese<br>Korean<br>Chinese<br>French<br>Spanish<br>Portuguese<br>Arabic

48.9kSign 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

Benchmarking NVMe-backed Managed Postgres: PlanetScale and ClickHouse

Sai Srirampur<br>Jul 30, 2026 · 5 minutes read

We launched PostgresBench, a fully reproducible, open-source benchmark for managed PostgreSQL services, a few months ago. It was well received, and we received valuable feedback from the community on how to evolve it.

One of the most common requests was to include locally NVMe-backed PostgreSQL services such as PlanetScale Postgres alongside ClickHouse Managed Postgres. Based on that feedback, we recently added PlanetScale Postgres (their Metal offering) to PostgresBench.

This blog presents the benchmark results and analyzes why the two services performed differently, even though both ClickHouse Managed Postgres and PlanetScale Postgres are built on similar NVMe-backed infrastructure.

Benchmark #

PostgresBench uses pgbench , PostgreSQL's standard benchmarking tool, with a TPC-B-like workload consisting of short, highly concurrent transactions with frequent inserts, updates, and deletes. To ensure the benchmark is not network-bound, we use PostgreSQL databases with 100 GB and 500 GB of data. Below is the pgbench command used for the benchmark.

The benchmark uses the following command:

1pgbench -c 256 -j 16 -T 600 -M prepared -P 30 \<br>2 -s $SCALE_FACTOR \<br>3 -h $PGHOST -p $PGPORT -U $PGUSER -d $PGDATABASECopy command

Hardware #

To ensure a fair comparison, both services were benchmarked using identical hardware .

AWS r8gd.xlarge and r8gd.4xlarge instances

Local NVMe storage

One primary with two synchronous standbys using quorum replication for high availability

us-west-2 AWS region

The benchmark client ran on a dedicated 16 vCPU, 64 GB instance in the same region, ensuring the client was never the bottleneck.

In short, both services were tested on the same VM family, instance sizes, region, and benchmark configuration.

Results #

~100 GB dataset (scale 6849) #

SystemMachineTPSAvg latency (ms)P95 (ms)P99 (ms)PlanetScale Metal16vCPU, 128GB RAM16,887.2315.14425.72932.894ClickHouse Managed Postgres16vCPU, 128GB RAM25,429.4810.07320.22829.146PlanetScale Metal4vCPU, 32GB RAM4,675.8554.71481.073103.579ClickHouse Managed Postgres4vCPU, 32GB RAM6,242.2941.05080.137115.215

The results show that ClickHouse Managed Postgres consistently outperformed PlanetScale Metal across both instance sizes. On the 16 vCPU / 128 GB configuration, ClickHouse delivered 25,429 TPS , about 51% higher throughput than PlanetScale's 16,887 TPS , while reducing average latency from 15.1 ms to 10.1 ms , ~33% lower .

On the 4 vCPU / 32 GB configuration, ClickHouse achieved 6,242 TPS vs 4,676 TPS , a ~34% higher throughput and reduced average latency from 54.7 ms to 41.1 ms (~25% lower).

Tail latencies (P95/P99) were comparable on the smaller instance and consistently lower on the larger instance.

~500 GB dataset (scale 34247) #

SystemMachineTPSAvg latency (ms)P95 (ms)P99 (ms)PlanetScale Metal16vCPU, 128GB RAM14,046.4218.23930.75638.608ClickHouse Managed Postgres16vCPU, 128GB RAM21,693.7111.80923.85931.369

The same trend continued with the larger 500 GB dataset. On the 16 vCPU / 128 GB configuration, ClickHouse Managed Postgres delivered 21,694 TPS , compared to 14,046 TPS for PlanetScale Metal, a 54% improvement in throughput . At the same time, average latency dropped from 18.2 ms to 11.8 ms , with P95 and P99 latencies also consistently lower.

Why is ClickHouse Managed Postgres faster than PlanetScale Postgres? #

The difference isn't the hardware. Both services were benchmarked on identical AWS r8gd instances with local NVMe storage, configured with one primary and two synchronous standbys using quorum replication. Both also acknowledge commits after one standby confirms the write (ANY 1), with synchronous_commit enabled.

The performance difference comes from how the services are engineered around PostgreSQL.

ClickHouse Managed Postgres applies several system-level optimizations that reduce CPU, memory, and I/O overhead. For example, it reserves memory using 2 MB huge pages, which reduces page-table overhead under highly concurrent workloads. On identical hardware, we measured this optimization alone improving throughput by about 12%.

The write path is also optimized. We enable wal_compression = lz4 and configure max_wal_size based on the instance size (up to 256 GB), reducing WAL volume and checkpoint frequency. This lowers the amount of data written to local NVMe and synchronously replicated to standbys.

Based on the PostgreSQL settings...