Skip to content
c17 .ioJoin list

Stacks / Backend

Medium

Vitess / TiDB

MySQL you scale yourself. Vitess is Apache-2.0 sharding; TiDB is Apache-2.0 distributed SQL — PlanetScale without the serverless seat.

The problem

PlanetScale is hosted MySQL with branching, built on Vitess. You wanted the clustering layer on hardware you control. Vitess is Apache-2.0 (vitessio/vitess). TiDB is Apache-2.0 (pingcap/tidb) if you want MySQL-compatible distributed SQL instead of a Vitess cell. This is not PlanetScale's branching workflow, Boost, or every serverless SKU. Postgres stays on /replace/neon.

Replaces

PlanetScale

Replace PlanetScale See all best open-source databases

Estimated SaaS saved

$1,200

per year, small team, before lock-in

Start on Railway

CloudNativePG / PostgreSQL if this is Postgres, not MySQL

Sponsor this stack Tip jar

Placeholder: Vitess is several components (vtgate, vtctld, MySQL tablets). TiDB is a cluster. A single Railway service is often the wrong size — a VM or Kubernetes is the honest path. No one-click template in this repo yet — Start on Railway. Postgres stays on /stacks/cloudnativepg-postgres.

The stack

Cost table

You stop payingTypical / yearSelf-host instead
PlanetScale (small team)$1,200Vitess or TiDB

Agent setup prompt

Replace PlanetScale with Vitess (preferred if you already think in MySQL shards) or TiDB (distributed SQL).

- Vitess: follow the official Kubernetes or local example. TiDB: TiDB + PD + TiKV as the project docs require.
- Import one schema. Do not claim PlanetScale branching. Write AGENT_PROMPT.md.
- Postgres stays on /stacks/cloudnativepg-postgres.

Also as markdown: /stacks/vitess-mysql.md

FAQ

Vitess or TiDB?
Vitess if you want sharded MySQL (the PlanetScale lineage). TiDB if you want distributed SQL that speaks MySQL. Pick one cluster.
Is this PlanetScale branching?
No. Branching is the hosted product. This page is the clustering layer you run.
Why not Neon?
Neon is Postgres (/replace/neon). PlanetScale is MySQL. Different engine.