Stacks / Backend
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
Estimated SaaS saved
$1,200
per year, small team, before lock-in
Start on RailwayCloudNativePG / PostgreSQL if this is Postgres, not MySQL
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 paying | Typical / year | Self-host instead |
|---|---|---|
| PlanetScale (small team) | $1,200 | Vitess 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.