PlanetScale

PlanetScale is a managed relational database service for Postgres and MySQL-compatible Vitess, with clusters across availability zones and a path to sharding.

PlanetScale hosts production relational databases so an engineering team can scale reads, writes and schema changes without operating database servers. PlanetScale, Inc., an independent San Francisco company whose founders co-created and maintain the open source Vitess project, builds and runs it. One account and one console cover three engines: Vitess for MySQL-compatible applications, PlanetScale Postgres, and Neki, a sharded form of Postgres. A team chooses the engine per database. High Availability clusters keep a primary and its replicas in separate availability zones. Writes use semi-synchronous replication, and a replica is promoted automatically when the primary fails. Metal clusters move storage onto local NVMe drives for I/O-heavy workloads. Database branching gives developers an isolated copy of the schema to change before shipping. On Vitess, a deploy request carries that change to production as a non-blocking schema change. Query Insights shows the queries running against a database, and point-in-time recovery replays archived write-ahead logs to restore a chosen moment. On Postgres, the extension library includes pgvector, TimescaleDB and pg_cron, connections pool through PgBouncer, and a TIN inverted index adds ranked text search. PlanetScale suits backend and platform engineers whose applications cannot pause for a failed primary or a locked table. MySQL teams that expect to outgrow one server start on Vitess, which shards horizontally. Teams committed to Postgres start on a single node or a High Availability cluster and move to Neki when one primary is no longer enough. A team signs up self-serve on the Base plan. Organisations that need PCI compliance, business support or PlanetScale Managed inside their own AWS or GCP account buy the Enterprise plan through sales. Common jobs include moving a production database off Amazon RDS, Aurora, Heroku, Neon or Supabase, and running sharded MySQL for a high-traffic application. Developers reach the database through ORMs such as Prisma and Drizzle and rehearse each migration on a branch before release. Data teams stream row changes out through logical replication, with Debezium or Fivetran carrying them to analytics systems. Security-minded teams connect over AWS PrivateLink or GCP Private Service Connect and watch the cluster in Datadog. It fits a product team that wants a sharded, failover-ready database tier without building Vitess or a Postgres replication setup of its own.