Skip to content

SYSTEM Cited by 4 sources

PlanetScale for Postgres

What it is

PlanetScale for Postgres is PlanetScale's Postgres hosting product, launched in private preview on 2025-07-01 (later Generally Available per the post's update banner). It runs real Postgres v17 — not a fork — under a proprietary control-plane / operator, with a proprietary proxy layer (including PgBouncer for connection pooling) handling query buffering during failover + pooling. Built on the same Metal direct-attached-NVMe cluster shape canonicalised on the MySQL side in March 2025.

PlanetScale for Postgres uses real Postgres running on our proprietary operator meaning we can bring the maturity of PlanetScale and the performance of Metal to an even wider audience. Today's release already achieves true high availability with automatic failovers, query buffering, and connection pooling via our proprietary proxy layer, which includes PgBouncer for connection pooling. We run Postgres v17 and support online imports from any version > Postgres v13, as well as automatic Postgres version updates without downtime.

(Source: .)

Architecture (as disclosed)

  • Engine: real community Postgres v17.
  • Control plane: PlanetScale's proprietary operator provisions and manages the Postgres cluster. Canonical wiki instance of concepts/proprietary-database-operator — the structural alternative to forking Postgres (DSQL-style extensions) or to compute-storage-separation rewrites (systems/lakebase / Neon).
  • Proxy layer: PlanetScale's proprietary proxy sits in front of the Postgres primary and replicas; it integrates PgBouncer for connection pooling and adds query buffering so clients don't see errors during automatic failover.
  • Cluster topology: Metal's primary + 2 replicas on direct-attached NVMe (inherited from the MySQL Metal launch) applies to Postgres on Metal. No artificial IOPS cap.
  • Import path: online imports from any Postgres version

    13; mechanism not disclosed in the post (candidates: logical replication, pg_dump + WAL catch-up).

  • Version upgrade path: "automatic Postgres version updates without downtime" — mechanism likely logical- replication-based blue/green, not disclosed.

Positioning

PlanetScale's own framing of why Postgres, why now:

  1. Customer-demand forcing function — Metal's March 2025 launch surfaced "an immense number of companies reaching out to us asking us to support Postgres. The demand was so overwhelming that by the end of launch day we knew we had to do this."
  2. 50+ customer pain-survey — "regular outages, poor performance, and high cost" consistent across the existing-vendor set. Same three pain axes (concepts/performance-variance-degradation + cost + reliability) Metal-for-MySQL targeted.
  3. "We are an engineering company" — performance parity / superiority was an entry requirement. The post claims "consistently outperform every Postgres product on the market, even when giving the competition 2x the resources", anchored on a separate benchmarking-methodology post.

Competitively, PlanetScale for Postgres sits across from:

PlanetScale's structural differentiation is real Postgres on direct-attached NVMe with a proprietary control plane — same open-source engine as RDS, but fundamentally different storage architecture.

Relationship to Vitess and Neki

The post is explicit: Vitess does not extend to Postgres.

Vitess is one of PlanetScale's greatest strengths and has become synonymous with database scaling. Contemporary Vitess is the product of PlanetScale's experience running at extreme scale. We have made explicit sharding accessible to hundreds of thousands of users and it is time to bring this power to Postgres. We will not however be using Vitess to do this.

Vitess' achievements are enabled by leveraging MySQL's strengths and engineering around its weaknesses. To achieve Vitess' power for Postgres we are architecting from first principles.

PlanetScale for Postgres today (launch-time) runs as a single-primary Metal cluster (primary + 2 replicas). The horizontal-sharding layer for Postgres is Neki, a separate under-construction system at neki.dev — waitlist-only at launch. Canonical wiki instance of patterns/architect-sharding-from-first-principles-per-engine — each engine gets its own purpose-built sharding layer.

Launch customer

Convex — "the complete backend solution for app developers, is migrating their reactive database infrastructure to PlanetScale for Postgres." Migration writeup: pscale.link/convex.

Caveats

  • Private-preview-at-launch. GA status came later (update banner in the post); no GA timeline disclosed at publication.
  • Architectural detail for the proprietary operator is absent. Provisioning, failover fencing, WAL archival, backup cadence, cross-AZ / cross-region replication, PITR granularity, extension-allowlist policy not disclosed.
  • Query buffering mechanics not characterised. Buffer depth, timeout, client-visible error contract, guarantees on idempotent vs non-idempotent statements, prepared- statement handling not stated.
  • PgBouncer deployment mode not stated. Session vs transaction pooling, per-user vs per-db pools, statement pooling availability, prepared-statement rewriting not disclosed.
  • Online-import mechanism not disclosed. Which tool / protocol bridges existing vendor → PlanetScale for Postgres.
  • No per-workload benchmarks in the post itself. Only the "2× resource parity beat" aggregate claim; competitor names, workload mix, percentile curves deferred to the separate methodology post.
  • Extension compatibility not enumerated. Specifically whether popular extensions (pgvector, pg_stat_statements, pgcrypto, postgis, pg_partman, etc.) are supported is not addressed.
  • Metal-for-Postgres operational footprint not quantified. Instance types, NVMe capacity ceilings, pricing delta vs Metal-for-MySQL, geographic regions on Metal not disclosed.

Seen in

  • sources/2026-04-21-planetscale-graceful-degradation-in-postgres — Canonical graceful-degradation framing for PlanetScale Postgres. Ben Dicken positions Traffic Control as the platform's load-shedding lever for user-facing spike survival: classify queries by critical / important / best-effort priority, apply per-tier resource budgets, shed the lowest tier via a live budget- disable under spike. Differentiator vs upstream Postgres / AWS RDS / GCP Cloud SQL Postgres — none of those have workload-class admission control via SQLCommenter-tagged priorities. Also canonicalises [PGINSIGHTS] Traffic Control: warnings delivered inside the Postgres query response as the application-facing observability channel for budget pressure.

  • sources/2026-04-21-planetscale-faster-planetscale-postgres-connections-with-cloudflare-hyperdrive — canonical customer-facing positioning as the authoritative store behind a Cloudflare edge stack. Simeon Griggs 2026-02-19 prediction-market demo uses the smallest Metal cluster ($50/month) as the source of truth; also notes the $5/month non-Metal tier as viable for the demo. The post reinforces "PlanetScale Postgres Metal is the benchmarked fastest cloud Postgres, so it makes sense to pair it with the fastest cloud services" and uses Query Insights + PlanetScale MCP server + database-skills.com agent skills as the post-load tuning loop for LLM-authored query code.

  • — launch announcement. Canonical introduction of the proprietary-operator + real-Postgres + Metal-cluster + PgBouncer-in-proxy shape; the Vitess-rejection + Neki-is- replacement story; the Convex launch-customer datum; the 50-customer pain-survey framing.

  • sources/2026-04-21-planetscale-benchmarking-postgres — methodology disclosure for the launch's "consistently outperform every Postgres product on the market" claim. Names the reference target: i8g M-320 — 4 vCPUs, 32 GB RAM, 937 GB NVMe SSD, with primary + 2 replicas across 3 AZs by default. Confirms PlanetScale for Postgres is on Metal (direct-attached NVMe) while all benchmarked competitors (Aurora, AlloyDB, CrunchyData, Supabase, TigerData, Neon) are network- attached-storage. Introduces the Telescope harness and the three-benchmark commitment (latency / TPCC / OLTP read-only), with full reproduction instructions and benchmarks@planetscale.com feedback address. Canonical instance of the new patterns/reproducible-benchmark-publication pattern and the new concepts/price-performance-ratio concept. Availability-posture-equalisation rule established: competitor price models include replicas to match PlanetScale's default 3-AZ posture.

  • — canonical demonstration that the product is a real Postgres with real logical replication at the $5 tier. Nick Van Wiggeren (PlanetScale SVP Engineering) builds a bidirectional 15 fps video chat by running a Node.js WebSocket relay (pg-relay, ~400 lines of TypeScript) against a $5 PlanetScale PostgreSQL cluster, inserting 25–40 KB JPEGs into a video_frames BYTEA column and forwarding them to clients via a logical replication slot. Canonical wiki signal that the logical-replication- as-pub/sub primitive is available and usable on the product's lowest tier — a load-bearing datum for any developer evaluating PlanetScale for Postgres for real-time workloads. The product's standard posture (real Postgres v17

  • full WAL + full logical-replication surface) is what makes this hack work without any PlanetScale-specific extensions; the BYTEA + publication + replication slot mechanics are community-Postgres-standard. Verified throughput: 15 fps bidirectional (76 rows per participant in a rolling 5-second window) at ~375–600 KB/s per direction. Source at github.com/nickvanw/PgVideoChat.
Last updated · 542 distilled / 1,571 read