PlanetScale

Overview

PlanetScale is a managed relational database platform for Vitess (MySQL-compatible) and Postgres. It is built by the team behind Vitess (originally created at YouTube) and led in part by infrastructure veterans from GitHub and related scale shops. Primary job: give application teams production MySQL or Postgres with Git-style schema workflows (branches and deploy requests), online schema changes, horizontal scale via Vitess sharding, and optional Metal (local NVMe) performance—without running Vitess or HA Postgres yourself.

Company site: planetscale.com. Pricing: planetscale.com/pricing. Docs: planetscale.com/docs. Status: planetscalestatus.com. Trust: trust.planetscale.com. GitHub: github.com/planetscale. CLI and API are first-class; Discord is the public community channel.

PlanetScale is aimed at teams that outgrow single-node hobby databases, need safe schema deploys on live traffic, or must shard MySQL at YouTube/Slack-class scale. Customers publicly named on the product site include Cash App, MyFitnessPal, Barstool Sports, Dub, and large product orgs (e.g. Anysphere/Cursor quoted on homepage for heavy Vitess and Postgres workloads). The product no longer markets a free Hobby tier (retired April 2024); entry is paid, with a low single-node Postgres option for development and small apps.

Key features

• Two engines: Vitess MySQL and Postgres — Vitess is the long-standing scale path (horizontal sharding, VTGate routing, production-grade online DDL). Postgres is a full managed offering with HA and single-node SKUs, PgBouncer pooling, extensions (e.g. pg_stat_statements, TimescaleDB where listed), PITR, and Traffic Control. Choose by app stack and scale model, not marketing.
• Branching and deploy requests — Create development branches, change schema in isolation, open a deploy request (schema diff + review), and deploy non-blocking changes to production. Vitess also supports Data Branching and revertable schema changes; Postgres branching exists with product-specific limits (e.g. deploy-request maturity differs by engine—check current Postgres branching docs).
• Online schema changes — Production DDL designed to avoid long table locks; online MySQL/Vitess version updates and online cluster resize/reshard on the Vitess path. Safe migrations can be enabled/disabled per branch.
• PlanetScale Metal — Locally attached NVMe instead of network-attached disks for high IOPS and lower latency. Marketed against Aurora/Cloud SQL–class EBS latency; Metal SKUs bundle compute with fixed NVMe sizes. Used by performance-sensitive production migrations (public case content from Cash App and others).
• Horizontal sharding (Vitess) — Explicit sharding with keyspaces, resharding workflows, and VTGates. Postgres horizontal sharding is product-roadmap territory (e.g. Neki announcements); do not assume Vitess-parity sharding on Postgres today.
• HA topology — Typical production branch: primary + two replicas across availability zones. Read-only regions (Vitess) for geo reads. Single-node Postgres is available and non-HA—fine for dev/cheap prod, not multi-AZ failover.
• Insights and ops — Query Insights (retention commonly 7 days on Base), query patterns reports, web console, automatic backups (every 12 hours on Base), user-scheduled backups billed separately, CLI shell/connect, webhooks, OpenAPI management API, service tokens, MCP/AI tooling for agents and IDE workflows.
• Connectivity — TLS connection strings; private connectivity via AWS PrivateLink and GCP Private Service Connect; IP restrictions (engine-specific); connection pooling via VTGates (Vitess) or PgBouncer (Postgres). Serverless drivers (e.g. database-js) for edge/serverless app patterns.
• Deployment options — Multi-tenant Base (self-serve); Enterprise single-tenant; PlanetScale Managed (data plane in your AWS/GCP account) for isolation, PCI shared-responsibility, and BYO cloud discounts (RI/Savings Plans on Metal where applicable).
• Compliance posture — SOC 1 Type 2 and SOC 2 Type 2+ HIPAA materials via Trust Center; HIPAA BAAs available on all plans (request flow in dashboard Legal); DPA on all plans; PCI DSS 4.0 Level 1 path primarily on Managed with shared-responsibility controls; encryption at rest and in transit (TLS).

Pricing

PlanetScale is subscription / usage billed at the database (cluster SKU) level under a self-serve Base plan, with custom Enterprise for Managed/single-tenant and support SLAs. There is no free plan (Hobby/Developer free tier ended April 2024). Prices below are indicative for AWS us-east-1 from the public pricing page; region and architecture (arm64 vs x86) change list price. Always confirm planetscale.com/pricing and plans docs.

Entry point	Starting price (list)	Topology	Notes
Postgres single-node PS-5	~$5/month	1 primary, no replicas	Dev, prototypes, small non-HA apps; 512 MiB / fractional vCPU
Postgres HA PS-5	~$15/month	1 primary + 2 replicas	Smallest HA Postgres SKU on network-attached storage
Vitess HA PS-10	~$39/month	1 primary + 2 replicas	Common production MySQL entry on Base (x86 list)
Postgres HA PS-10 / PS-20…	From ~$30–$50+	3-node HA	Arm64 often cheaper than x86 at same SKU
Metal (Postgres/Vitess)	From tens to thousands $/mo	HA + NVMe size options	e.g. M-10 Postgres Metal from ~$50 list with small NVMe; large M-series into five figures
Enterprise / Managed	Custom	Single-tenant or BYO cloud	PCI path, dedicated support, marketplace billing options

• Storage (network-attached) — Roughly 10 GB included per instance class; overage often quoted around $0.50/GB/instance/month. HA production storage is effectively ~3× that footprint (primary + 2 replicas; docs cite ~$1.50/GB for HA production branch storage math).
• Egress — Community and third-party pricing summaries commonly cite ~100 GB included then ~$0.06/GB; verify live invoice line items for your region.
• Backups — Automated every 12 hours on Base; extra user-scheduled backups commonly billed around $0.023/GB/month.
• Vitess development branches — ~1,440 hours/month included (≈2 always-on PS-DEV equivalent); overage ~$0.014/hour. Postgres development branches are billed as small clusters (docs: ~$5/month class), not the same included-hours model.
• Add-ons — SSO ~$199/month on Base; Business support; extra production branches = full additional cluster SKU; read-only regions; VTGates/replicas beyond base topology; private connectivity as configured.
• SKU unlock — Cluster sizes above PS-160 / M-320 often require a paid invoice of at least $100 before self-serve unlock (contact sales to skip).
• Proration — Resize and mid-cycle creates bill by the millisecond; temporary upsizing only costs the window you run larger.

Limits & gotchas

• No free tier — Hobby ended April 2024. Credit card and paid Base plan required to create databases. Side projects that expected forever-free MySQL moved to Neon, Supabase, Turso, self-host, or similar.
• Engine differences — Feature parity is incomplete: Data Branching and mature Vitess deploy workflows are MySQL-path strengths; Postgres has its own branching/PITR/extensions model. Foreign keys are supported on Vitess with historical caveats (early years required app-level integrity; FK support was added later with deploy-request edge cases).
• Vitess is not vanilla MySQL — Triggers, some stored procedures, and certain MySQL features can be restricted or non-portable at scale. Shard-aware query patterns matter; cross-shard transactions are the classic Vitess tax.
• Single-node ≠ production HA — PS-5 single-node has no replica failover. Do not use it as a silent production default for SLAs.
• Branch cost models differ — Spinning many long-lived Postgres dev branches can bill like many small databases; Vitess includes a monthly hour pool. Idle branches still cost if left running.
• Insights retention — Base query insights retention is short (docs: 7 days). Long forensic windows need external logging or Enterprise packaging.
• Regional price variance — us-east-1 list prices are not global; multi-region read-only replicas add storage and compute.
• Lock-in is operational, not proprietary SQL — MySQL/Postgres dialects are standard, but branching workflows, Vitess sharding keys, and Metal ops are PlanetScale-specific. Migrations in/out use logical dumps, CDC, or import tooling (Aurora/Heroku guides exist for Postgres).
• Support tiers — Base standard support is not enterprise TAM/Slack; Business and Enterprise upgrades cost extra. Mission-critical SLAs (public multi-region claims up to 99.999% / single-region 99.99% on marketing SLA pages) are contract-bound for serious estates.

Community sentiment

Across Reddit (r/webdev, r/nextjs, r/PostgreSQL), Hacker News, PeerSpot, TrustRadius/G2 listings, and engineering blogs, the pattern is consistent:

• Praise: Online schema deploy workflow feels like Git for databases; Vitess expertise and scale stories are credible; Metal NVMe performance wins heart share for latency-sensitive OLTP; Postgres launch (GA discussions on HN) and $5 single-node entry repaired some goodwill after free-tier removal; Insights and CLI DX beat raw RDS for many teams. PeerSpot averages are often cited around ~8.4/10 on limited sample sizes—treat as directional.
• Complaints: Free-tier removal (April 2024) remains a cultural scar—HN and Reddit still reference it when free tiers of competitors change. Historical “no foreign keys” reputation lingers even after FK support. Cost surprise when HA + storage + branches stack. Early serverless/edge connection patterns required careful driver choices. Some teams prefer pure Postgres (Neon, Supabase, RDS) for ecosystem and free tiers.
• When teams stay or return: Need to shard MySQL without hiring a Vitess team; want online DDL with review; Metal price/performance vs Aurora; enterprise Managed/PCI; already MySQL-native apps (Prisma/Drizzle) that fit Vitess well.

“PlanetScale is the rare DBaaS that sells workflow and scale craftsmanship—not just a VM with MySQL installed. You pay for that craftsmanship once the free tier is gone.” — paraphrased consensus from HN free-tier and Postgres GA threads

Who should use it

• Production MySQL teams approaching vertical scale limits who need Vitess-grade sharding and online schema changes without self-managing Vitess.
• Product engineering orgs that want branch → deploy request → online migrate as a standard pipeline (similar rigor to code review).
• Latency-sensitive OLTP workloads evaluating Metal NVMe against Aurora/Cloud SQL network disks.
• Postgres teams who prefer PlanetScale’s ops/Insights/Metal story over serverless scale-to-zero economics—and can accept paid entry.
• Regulated or enterprise buyers needing SOC reports, BAA, private connectivity, or Managed in their own AWS/GCP account / PCI shared model.
• Less ideal: Hobbyists who need a permanent free database; pure Postgres shops that want Neon/Supabase free tiers and full extension freedom; teams that require every MySQL feature Vitess soft-limits; or apps that only need a $0 weekend project DB.

Alternatives

• Neon — Serverless Postgres with branching and a free tier; best when scale-to-zero and pure Postgres DX matter more than Vitess sharding.
• Supabase — Postgres plus auth, storage, and edge functions; better “backend platform” than database-only PlanetScale.
• MySQL (self-managed / other hosts) — When you want full server control or cheaper single-node hosts without PlanetScale workflow.
• Railway / Render — App-platform databases for simpler deploy-and-forget stacks; weaker at large-scale sharding.
• Amazon Aurora / RDS — Default enterprise MySQL/Postgres on AWS; deeper AWS integration, more DIY ops for online DDL and branching.
• CockroachDB / TiDB — Distributed SQL alternatives when you need multi-region active-active or HTAP-style scale with different consistency models than Vitess.

Verdict

PlanetScale is a premium managed MySQL (Vitess) and Postgres platform optimized for safe schema change workflows and high-performance production scale—not a free hobby database. Pay for HA cluster SKUs (and Metal when I/O dominates), treat $5 single-node as a foot in the door, and pick Vitess when horizontal MySQL scale is real. Choose Neon/Supabase/RDS when free tiers, pure Postgres ecosystem, or AWS-native procurement dominate. For teams already feeling the pain of locking DDL or hand-rolled Vitess, PlanetScale’s workflow and ops model remain among the strongest commercial answers in 2026.