Skip to content

CONCEPT Cited by 2 sources

Price-performance ratio

Definition

The price-performance ratio (equivalently: cost per unit of performance, $/QPS, $/TPS, cost-per-IOPS) is the consumer-facing metric that answers "how much does it cost to achieve some bar of performance, relative to another option?" It is the fourth question a useful database benchmark answers, after:

  1. How quickly can I reach my database? (latency)
  2. How does it perform under typical OLTP load? (TPS / QPS)
  3. How does it perform under high read / write pressure? (IOPS, caching)
  4. How much does it cost to achieve some bar of performance? (price:performance)

(Source: sources/2026-04-21-planetscale-benchmarking-postgres)

Why it's a separate concept

The raw performance numbers from a benchmark don't close the procurement decision. Two configurations can have identical throughput at wildly different monthly costs, and no single-vendor benchmark surfaces the cost axis without explicit bookkeeping. Key reasons the ratio must be computed separately:

  • Vendor SKUs are heterogeneous. Aurora prices compute + storage + I/O separately; PlanetScale bundles; Neon's compute autoscales; Supabase uses project + storage + egress. Apples-to-apples total cost requires reconstructing each vendor's monthly bill under the benchmark workload.
  • Availability posture is load-bearing. A single-instance competitor costs less than a 3-replica deployment, but doesn't deliver the same availability. PlanetScale's methodology adds replicas to competitor cost models to match PlanetScale's posture:

    To match the true capacity and availability of PlanetScale, each would also need to add replicas. We account for this when discussing pricing. (Source: sources/2026-04-21-planetscale-benchmarking-postgres)

  • Storage + IOPS are priced differently from compute. i7i.2xlarge with 1.8 TB local NVMe at $551.15/mo has more storage than r7i.2xlarge + gp3-3k at $442.32/mo. The price column doesn't just track CPU/RAM; IOPS cap + NVMe capacity materially shift the ratio. (Source: sources/2025-10-14-planetscale-benchmarking-postgres-17-vs-18)
  • Vendor offerings cap at different RAM:CPU ratios. Supabase / TigerData / Neon cap at 4:1 RAM:CPU; Aurora / AlloyDB / CrunchyData support 8:1. Matching RAM across vendors forces asymmetric CPU counts and therefore asymmetric pricing. PlanetScale's methodology explicitly gives 4:1-cap competitors "double the CPU count" to match RAM, calling out that "this is an unfair advantage to them" — but the price column still includes that larger CPU allocation.

Canonical instance (PlanetScale Metal for Postgres, 2025-10-14

Postgres 17 vs 18 benchmark)

From the [[sources/2025-10-14-planetscale-benchmarking-postgres-17-vs-18|2025-10-14 Postgres 17 vs 18 benchmark]]:

Configuration Monthly cost Storage IOPS cap
r7i.2xlarge + gp3 (3 k IOPS default) $442.32 700 GB 3,000
r7i.2xlarge + gp3 (10 k IOPS) $492.32 700 GB 10,000
r7i.2xlarge + io2 (16 k IOPS) $1,513.82 700 GB 16,000
i7i.2xlarge (local NVMe) $551.15 1,800 GB none (∼300 k)

The i7i.2xlarge with local NVMe wins every benchmark scenario tested and costs less than io2 at a third of io2's storage-cost factor. The ratio isn't just "NVMe is faster" — it's "NVMe is faster and cheaper and bigger, at every workload PlanetScale tested."

This is the empirical backing for PlanetScale Metal's architectural positioning: direct-attached NVMe isn't a performance luxury, it's the dominant price-performance point on the shipped Postgres 18 stack.

Methodology failure modes

The price-performance ratio is vulnerable to the same bias classes as raw performance benchmarks, plus accounting-specific failure modes:

  • Stripping replicas from competitor cost. A 1-node competitor next to a 3-replica reference gives the 1-node competitor a 3× price advantage that evaporates once availability is equalised.
  • Ignoring storage capacity. An instance shape with more storage is cheaper per GB even at similar compute. Not normalising ($/GB and $/QPS) obscures this.
  • Ignoring IOPS-vs-no-IOPS-cap. Local NVMe on i7i has no artificial cap; EBS gp3 has a default 3,000 IOPS cap that the benchmark can hit long before CPU or RAM limits.
  • Ignoring burst vs sustained pricing. Supabase / Neon / TigerData have autoscaling compute and storage burst pricing; a 5-minute benchmark window doesn't exercise sustained cost.
  • Egress / backup / replication costs. PITR, backup retention, and cross-region replication often sit outside the baseline instance price.
  • Vendor-specific per-feature pricing. Atlas vector search nodes, Aurora Limitless, Postgres extensions as paid tiers — comparable workloads may require different feature tiers at different vendors, breaking the $-per-performance comparability.

Seen in

Last updated · 319 distilled / 1,201 read