PlanetScale: MySQL-Compatible Serverless Database with Schema Branching

Your team just pushed a migration that locked a production table for 40 seconds. Orders stopped processing, the on-call engineer scrambled, and the post-mortem dragged on for two hours. This is the silent tax MySQL teams pay when schema management is bolted on as an afterthought. PlanetScale is built to eliminate that tax entirely — it treats schema changes as first-class citizens, gives them their own branch-and-review workflow, and executes DDL without ever acquiring a table lock. If your stack runs MySQL in production and you have ever winced before running ALTER TABLE, keep reading.

What Is PlanetScale?

PlanetScale is a database-as-a-service platform that exposes a fully MySQL-compatible wire protocol on top of Vitess, the open-source clustering middleware originally built at Google to scale YouTube's MySQL infrastructure. When you connect to PlanetScale from your application, your existing MySQL drivers, ORMs, and query patterns work without modification. Under the surface, Vitess handles connection pooling, query routing, and horizontal sharding.

The platform is serverless in the sense that you do not provision instances or manage server capacity. You connect, query, and pay for what you use. PlanetScale auto-scales read replicas and compute behind the scenes. This positions it alongside Neon (serverless Postgres) and Supabase (Postgres with batteries included), but squarely in the MySQL ecosystem — a meaningful distinction for teams with existing MySQL schemas, stored procedures, or ORM configurations.

PlanetScale's standout differentiator is not the serverless compute model itself — it is the schema workflow. Every database comes with the concept of branches, and schema changes flow through those branches with the same rigor as application code moving through a CI/CD pipeline.

Schema Branching Workflow

Every PlanetScale database starts with a main branch, which maps to your production database. You never apply migrations directly to main. Instead, the workflow looks like this:

1. Create a development branch from main. This is a full logical copy of your schema (data is not copied; the branch shares the underlying storage infrastructure).
2. Apply your migration against the development branch using any tool you already use — raw SQL, Flyway, Liquibase, Prisma Migrate, or plain mysql CLI.
3. Open a deploy request — PlanetScale's equivalent of a pull request. The platform diffs the schema between your development branch and main, shows you exactly what DDL will run, and lets teammates review it.
4. Merge the deploy request. PlanetScale executes the migration against main using non-blocking DDL. You can queue multiple deploy requests and promote them one by one.

There is also a shadow branch concept that PlanetScale uses internally. When a deploy request is created, PlanetScale automatically provisions a shadow branch that mirrors main and applies your migration to it first. This lets the platform validate the DDL against real production schema state before the deploy request can be merged.

Installing the pscale CLI gives you a local development loop:

# Authenticate
pscale auth login

# Create a branch
pscale branch create my-database add-user-preferences --from main

# Open a local proxy to the branch (no TLS config needed)
pscale connect my-database add-user-preferences --port 3309

# Apply your migration via any MySQL client
mysql -h 127.0.0.1 -P 3309 -u root my_database < migrations/0012_add_preferences.sql

# Open a deploy request
pscale deploy-request create my-database add-user-preferences

The proxy command deserves attention: pscale connect tunnels an authenticated, TLS-terminated connection from localhost to PlanetScale. Your local application connects to 127.0.0.1:3309 with no credentials — the CLI handles auth. This makes local development frictionless and eliminates certificate management during inner-loop development.

Non-Blocking Schema Changes

This is the technical heart of PlanetScale's value proposition. Traditional MySQL DDL operations like ALTER TABLE ADD COLUMN or ALTER TABLE ADD INDEX acquire a metadata lock and block reads and writes on the affected table for the duration. On a table with tens of millions of rows, that can mean minutes of downtime. Tools like pt-online-schema-change and gh-ost exist precisely to work around this limitation.

PlanetScale solves this at the platform level using vreplication, Vitess's internal replication engine. When you merge a deploy request, PlanetScale does not run the raw DDL against your production table. Instead, it:

1. Creates a new table with the target schema alongside the existing table.
2. Streams existing rows from the old table into the new table in batches while your application continues reading and writing the original.
3. Tracks ongoing writes to the original table using binary log streaming and applies them to the new table in near real time.
4. When the new table has caught up to within milliseconds of the original, it performs a near-instantaneous atomic cutover — swapping the table name at the storage layer.

The result: your application sees zero downtime and zero lock waits during the migration, regardless of table size. A 500 GB table gets migrated the same way a 500 KB table does — safely, in the background.

Vitess Under the Hood

Understanding Vitess helps you reason about PlanetScale's behavior and its constraints. Vitess sits between your application and MySQL as a proxy and orchestrator. It maintains a connection pool, routes queries across shards, and rewrites queries when necessary to enforce shard key boundaries.

This architecture delivers real benefits: PlanetScale can transparently horizontal-shard your database across multiple MySQL instances without application changes. On paid plans (Scaler Pro and above), you can define a sharding key and PlanetScale will distribute rows across shards based on that key. Reads and writes to a single shard remain fast; cross-shard queries are handled by Vitess's scatter-gather mechanism.

Connection strings look like standard MySQL DSNs. You obtain them from the PlanetScale dashboard or CLI:

pscale password create my-database main production-app

This outputs a username, password, and hostname. Your DSN becomes:

mysql://username:password@aws.connect.psdb.cloud/my_database?ssl=true

All PlanetScale connections require TLS. The ?ssl=true parameter (or its ORM equivalent) is mandatory. Most MySQL drivers support this natively.

Pricing

PlanetScale uses a consumption-based pricing model with a generous free tier:

• Hobby (free): 5 GB storage, 1 billion row reads per month, 10 million row writes per month. One production branch, one development branch. No sleeping (databases stay live). Suitable for side projects and staging environments.
• Scaler ($29/month per database): 10 GB included storage, higher read/write quotas, additional development branches, and access to deploy request queuing. Overage pricing applies beyond included limits.
• Scaler Pro ($39/month and up): Resource-based pricing (vCPU + memory), horizontal sharding, advanced insights, and 99.999% uptime SLA. Designed for production workloads with predictable scaling needs.
• PlanetScale Metal: A self-hosted deployment option where PlanetScale manages the software layer (Vitess) but you bring your own infrastructure. Targets enterprises with data residency requirements or existing infrastructure contracts.

Compared to Neon (serverless Postgres) and Supabase, PlanetScale's free tier is more generous on row read volume and does not pause idle databases. Neon pauses compute after inactivity (which can cause cold-start latency), while Supabase pauses free projects after one week of inactivity. PlanetScale's free databases stay live. However, Neon and Supabase both support foreign keys — a significant consideration if your schema relies on them.

Limitations

Beyond foreign key constraints, there are a few other limitations to be aware of before committing to PlanetScale:

• No stored procedures or triggers in deploy requests: Stored procedures and triggers can be created but are not tracked by PlanetScale's schema diffing engine. They require manual management and are easy to let drift across branches.
• Vitess query compatibility: Vitess rewrites some queries. Certain subquery patterns, SELECT ... INTO, and some window function combinations may behave differently or require adjustment. Test your query workload against a PlanetScale branch before migrating production.
• Single-region on lower tiers: The Hobby and base Scaler plans are single-region. Multi-region read replicas require Scaler Pro or higher.
• Connection limits: Because Vitess pools connections internally, you get a much higher effective connection limit than raw MySQL, but very high connection counts (thousands of persistent connections from serverless function cold starts) still require careful management or a connection pooler like PlanetScale's built-in pooling.

Key Takeaways

Explore More Database Comparisons on JusDB

PlanetScale is one of the most thoughtfully engineered databases in the MySQL ecosystem, but the right database depends on your workload, schema design, and operational constraints. JusDB maintains deep technical profiles on PlanetScale, Neon, Supabase, CockroachDB, PlanetScale Metal, and dozens of other modern databases — with real configuration examples, pricing breakdowns, and migration guides written for engineers.

Browse the JusDB database directory to compare PlanetScale side-by-side with alternatives, or explore our technical blog for in-depth guides on schema management, connection pooling, and production MySQL patterns.