PlanetScale vs Crunchy Data benchmarks
This page includes benchmarks that compare the performance of Postgres on PlanetScale with Postgres on Crunchy Data, along with all of the resources needed to reproduce these results. We also recommend reading our Benchmarking Postgres blog post, which covers the methodology used in these benchmarks and the steps taken to maintain objectivity. We invite other vendors to provide feedback.
TPCC Benchmark configuration
Provider & Instance | Region | vCPUs | RAM | Storage | IOPS |
---|---|---|---|---|---|
PlanetScale M-320 | us-east-1 | 4 | 32GB | 929GB | unlimited |
Crunchy Memory-32 | us-east-1 | 4 | 32GB | 929GB | 6k-40k variable |
- Configuration: All Postgres configuration options left at each platform's defaults, except for connection limits and timeouts which may be modified to facilitate benchmarking.
- Benchmark machine: Benchmarks were executed from a
c6a.xlarge
in us-east-1, the same region as both databases.
TPCC Benchmarks
TPCC is a widely-used benchmark to measure general-purpose OLTP workload performance. This includes selects, inserts, updates, and deletes.
Benchmark data: A TPCC data set generated with TABLES=20
and SCALE=250
using the Percona sysbench-tpcc
scripts. This produces a ~500 gigabyte Postgres database. You can replicate the data following these instructions.
Benchmark execution: Using the Percona tpcc scripts running a load with 100 simultaneous connections. We run the load on each database for 5 minutes (300 seconds).
Queries per second
Our first benchmark measures queries per second (QPS) at 32 connections and 64 connections, revealing a significant difference:
Click the graphs in the sidebar to toggle the number of connections. The PlanetScale database averaged ~17,000 QPS. Crunchy Data averaged ~8000 QPS, with large dips approximately every 60 seconds. The key advantage to PlanetScale here is the use of locally-attached NVMe drives in AWS.
p99 latency
We also measured the p99 latency for the duration of the benchmark run (lower is better):
Despite both being in us-east-1
, PlanetScale shows much lower latency due to locally-attached NVMe drives with unlimited IOPS, 8th-generation AArch64 CPUs, and high-performance query path infrastructure.
Query-path latency
We measured pure query-path latency by running SELECT 1;
200 times on a single connection. This tests the overhead of any database query.
Results compare PlanetScale + PSBouncer, standard PlanetScale connection, direct-to-Postgres on PlanetScale, and a direct connection to Crunchy. Lower is better.
Direct connections to PlanetScale are significantly better than Crunchy. Though, to be transparent, the direct connection to PlanetScale is same-AZ, which may provide an advantage depending on the AZ of the Crunchy node.
Cost
A PlanetScale M-320 with 929GB of storage costs $1,399/mo. This includes three nodes with 4 vCPUs and 32GB RAM each, one primary and two replicas. Replicas can be used for handling additional read queries and for high-availability. The benchmark results shown here only utilized the primary.
For Crunchy, a single Memory-32
node costs $480.00/mo, and the 929GB volume costs $92.90 for a total of $572.90. In order to match the availability and capability of the 3-node setup of PlanetScale, we would also need two replicas, bringing the cost to $572.90 * 3 = $1718.70/mo.
PlanetScale offers better performance at a lower cost for applications that require high availability and resiliency.