PlanetScale Productized Vitess, Then Priced Out the Hobby Tier

Serverless database marketing still sells magic: spin up a URL, forget the DBA, scale like YouTube. PlanetScale sells that surface too—but the durable story is quieter. PlanetScale is a Vitess hosting company whose business model is schema custody: wrap YouTube-grade MySQL sharding in branching and deploy requests, monetize the control plane where migrations become Git-like reviews. Judge it on whether your team can leave with a portable dump and a Vitess escape hatch—not on whether "PlanetScale" clears a generic brand-naming worksheet.

The scar was YouTube scale, not a category slide

The useful frame is not "serverless MySQL." It is commercializing an open-source sharding layer other companies kept rebuilding badly.

At YouTube in the late 2000s, MySQL was cracking under growth—roughly 100M views/day when Jiten Vaidya arrived in 2007, past 2B/day by 2012 per founding interviews (TechCrunch, 2018). Sugu Sougoumarane and Jiten Vaidya co-created Vitess: horizontal sharding middleware that lets apps talk to segmented MySQL as if it were one database. Vitess went open source, graduated the CNCF, and now runs at Slack, GitHub, Square, HubSpot, and Etsy—not marketing fiction.

By 2017–2018, the pair kept fielding the same question: who do we pay to run Vitess for us? They incorporated PlanetScale (late 2017 per Vaidya's own timeline; public launch December 2018) with a $3M seed led by SignalFire and a roster of infra luminaries—Steve Chen, Aditya Agarwal, Adam D'Angelo, and Sam Lambert (then GitHub's head of platform) among the angels (WebWire).

Early PlanetScale was not a polished "create database" button. It was training, support, licensing, and BYOK Vitess on Kubernetes—infrastructure services for teams that already knew they needed sharding. The SaaS product most developers recognize arrived later.

Product arc: support shop → serverless MySQL → Postgres fork in the road

The company’s trajectory is a case study in packaging depth engineering as developer UX—and the margins that follow.

| Era | What shipped | Strategic move | | --- | --- | --- | | Dec 2018 | Stealth exit; Vitess services | Monetize expertise before product polish | | May 2021 | Hosted "developer-first" DB (beta) | Abstract zones, cluster sizes, Vitess ops | | Jun 2021 | $30M Series B (Insight); total ~$55M | Scale GTM around serverless narrative | | Jul 2021 | Sam Lambert → CEO; Jiten Vaidya → CSO/board | Product/GTM operator replaces founder-CEO | | Nov 2021 | $50M Series C (Kleiner Perkins); GA; total $105M | Enterprise credibility; last funding to date | | 2021–2023 | Branching + deploy requests (online DDL) | Moat = migration workflow, not raw MySQL | | Feb 2023 | Sugu Sougoumarane departs (CTO/co-founder) | Vitess DNA walks; strategic drift begins | | Mar 2024 | Hobby tier sunset + sales/marketing layoffs | Profitability over developer top-of-funnel | | 2025 | PlanetScale Metal (local NVMe); Postgres GA (Sep) | Hardware bet + Postgres land grab | | 2025–2026 | Neki (proprietary Postgres sharding, closed) vs Multigres at Supabase (open, Sugu) | Two "Vitess for Postgres" visions diverge |

Lambert—former GitHub VP Engineering, PlanetScale CPO for nine months—became CEO in July 2021 (company blog). Business Insider later reported 10+ GitHub hires in a year, including senior engineering leadership. That hire pattern signals intent: sell the GitHub-adjacent workflow (branch, review, merge) to teams with production MySQL pain.

The headline features map cleanly to Vitess strengths:

• Branching: schema-first dev environments; not Neon-style copy-on-write data snapshots on MySQL.
• Deploy requests: reviewed, non-blocking schema changes via online DDL—production stays up while ALTER TABLE ships.
• Sharding: explicit horizontal scale when single-shard MySQL stops fitting—PlanetScale's original reason to exist.

Foreign keys were long a flashpoint (Vitess historically discouraged them); PlanetScale later added opt-in FK support on unsharded databases with documented revert/orphan edge cases (FK blog). That is compatibility catching up to ORM defaults—not the core moat.

Business model tension: free tier acquisition vs "forever" reliability

PlanetScale's hardest lesson is margin structure in developer infra.

Managed Vitess is expensive: always-on clusters, replication, control-plane SRE, and support for mission-critical data. The Hobby (free) tier bought top-of-funnel love—tutorial traffic, side projects, framework defaults—while enterprise logos (Block, Cursor, Intercom per 2025 Postgres GA post) paid the real bills.

On March 6, 2024, Lambert published PlanetScale forever: retire Hobby on April 8, cut sales and marketing headcount, and prioritize profitability so the company would not depend on the next funding environment to survive. The Register quoted Lambert saying the free tier cost millions and attracted users PlanetScale was "not perfect for"—teams without large-scale or HA needs.

The developer backlash was predictable:

• One-month migration window for sleeping databases vs peers who extended runway (Railway credited hobby users when it raised prices).
• No cheap on-ramp: smallest paid cluster (PS-10 / Scaler Pro) landed around $39/month in public commentary—fine for production, harsh for experiments.
• Narrative whiplash: years of "serverless MySQL for everyone" marketing, then explicit opt-out of database hype and free-resource giveaways in the same post.

PlanetScale's support docs now state plainly: no free plans (support article). Single-node Postgres on Metal advertises from $5/month—a lower entry for Postgres-only workloads, not a return of unlimited free MySQL.

This is coherent strategy if you believe Vitess SaaS is an enterprise reliability product. It burns trust if you believed the brand was Neon with MySQL syntax.

Competitors: same "serverless database" brochure, different custody

| | PlanetScale | Neon | Turso | CockroachDB | | --- | --- | --- | --- | --- | | Engine | MySQL via Vitess; Postgres (Metal) | Serverless Postgres | libSQL (SQLite) at edge | Distributed SQL (Postgres wire) | | Sweet spot | Non-blocking MySQL DDL; Vitess sharding | CoW branching; scale-to-zero Postgres | Sub-ms edge reads; DB-per-tenant | Multi-region OLTP; strong consistency story | | Branching | Schema workflow + deploy requests (MySQL); backup-based on Postgres | Instant data+schema CoW branches | No native Git-like schema workflow | Limited vs Neon/PlanetScale DX | | Free tier (2026) | No (since Apr 2024) | Yes (generous Postgres sandbox) | Yes (edge SQLite) | Limited trial / self-host CE | | Lock-in shape | Deploy requests + Vitess routing | Neon storage/compute split | Turso edge replication + libSQL | Cockroach SQL + multi-region ops | | Open core | Vitess (CNCF) | Postgres + open platform pieces | libSQL open source | BSL / source-available |

Choose Neon when you are Postgres-native, want data-rich branches for CI, scale-to-zero economics, or a permanent free tier—and can live inside Postgres custody (Neon joined Databricks in 2025; Lakebase narrative evolving).

Choose Turso when the workload is read-heavy, edge-local, SQLite-shaped—embedded replicas, tenant-per-database, not complex MySQL JOIN farms at write-heavy QPS.

Choose CockroachDB when the buyer wants globally distributed OLTP with a Postgres-compatible wire protocol and can budget for distributed-ops complexity—not Vitess-style application-aware sharding.

Choose PlanetScale when you are MySQL-shaped, need online schema change governance, and expect to grow into Vitess sharding—and you accept paid-only positioning plus Vitess compatibility caveats (FK/sharding limits, lint rules).

Adjacent names without drowning this piece: Supabase (Postgres BaaS + Multigres sharding bet), AWS Aurora / Google AlloyDB (managed Postgres/MySQL at hyperscaler gravity). Pick on custody boundary—not roundup lists.

The Postgres pivot and the Multigres fork

Postgres won mindshare; PlanetScale could not ignore it.

September 22, 2025, PlanetScale announced Postgres GA on Metal (direct-attached NVMe, HA across three AZs) (GA blog). Benchmark marketing targets Aurora, AlloyDB, Neon, Supabase—classic "we're faster" infra positioning.

But the sharding story forked:

• PlanetScale's Neki is a proprietary Postgres sharding layer—not a Vitess fork—built from first principles; open sourcing promised later via neki.dev when ready.
• Sugu Sougoumarane, Vitess co-creator and PlanetScale co-founder/CTO until February 2023, joined Supabase in June 2025 to lead Multigres—explicitly "Vitess for Postgres" as open source (Supabase announcement). Sugu's public framing: after three years away, PlanetScale was a different company; the question shifted from "what should PlanetScale's co-founder do?" to "what should Vitess's co-creator do?"

PlanetScale docs now draw a product line: Vitess for near-term horizontal sharding at massive QPS; Postgres for teams staying on PostgreSQL until Neki matures (Postgres vs Vitess). Deploy requests remain Vitess-only today—Postgres branches exist, but the Git-like merge workflow that defined PlanetScale's brand does not fully carry over.

That split is the pivot challenge in one paragraph: monetize Vitess expertise, chase Postgres TAM, lose the open-source sharding co-founder to a competitor's open Multigres, and ask enterprises to trust closed Neki against CNCF Vitess pedigree.

The name and domain (briefly—facts beat folklore)

The old startup-showcase template treated naming as the headline. The verified story is shorter:

• PlanetScale is literal infra vocabulary: planet-scale workloads—global, sharded, never-out-of-headroom ambition. Not an acronym hunt.
• planetscale.com is the product, docs, and marketing hostname—clean exact-match .com, no .io phase in public lore.
• Social handles historically used @planetscaledata on some networks; the brand compresses to PlanetScale in prose.
• Vitess lives at vitess.io as the open project; PlanetScale sells managed custody of it, not the name Vitess on the tin.

That is positioning vocabulary—not a naming-pillar scorecard.

Prove the exit ramp: a dump + deploy-request audit

Schema custody is not a homepage adjective. Run this before you treat branching as portable:

1. Export with tools you already trust. Take a logical dump (mysqldump or PlanetScale's documented export paths) of schemas and data you need. Record size, time, and whether Vitess-specific routing tables or VSchema JSON are documented outside the dump.

2. Inventory deploy-request-only changes. List migrations that exist only as PlanetScale deploy history—not in your repo's SQL. If production schema truth lives in the dashboard, you do not own an exit—you own a habit.

3. Rehearse on plain MySQL or self-hosted Vitess. Restore the dump to a non-PlanetScale target your app actually uses. Run read/write paths, especially queries that relied on Vitess query rewriting or connection pooling via the serverless driver.

4. Count Vitess lint surprises. Foreign keys, ENUM changes, shard keys, and charset lint errors that PlanetScale blocked in deploy requests will become your problem elsewhere—grep deploy-request error logs.

5. Document the delta. Date the drill. If nobody can get green schema + app tests off-platform in a sprint, you are renting migration workflow—not renting MySQL.

What to verify before your team standardizes on it

1. MySQL vs Postgres product choice. Vitess path for sharded MySQL; Postgres Metal for HA Postgres without deploy requests today—do not assume one account gives you both workflows.

2. Free-tier absence. Budget paid-only from day one; hobby tutorials referencing PlanetScale Hobby are obsolete after April 2024.

3. Branch semantics. MySQL branches are schema-first; do not expect Neon-style instant full data clones unless you use Postgres backup branches (slower, storage-heavy).

4. Sharding horizon. If you are sub-terabyte single-shard today, confirm you need Vitess ops—not just a managed MySQL with pretty DDL—before accepting lint and routing constraints.

5. Open-source alignment. Teams betting on open Multigres at Supabase vs closed Neki at PlanetScale are making a governance bet, not just a performance bet.

PlanetScale's competitive edge is not the loudest "serverless MySQL" billboard. It is YouTube's sharding middleware repackaged as deploy-request custody—$105M raised, profitable-by-choice since 2024, Postgres GA in 2025, and a free tier deliberately killed so the company could claim forever. Price the control plane—and run the dump drill before deploy requests become your only source of schema truth.