Planetscale review after 2 years in production

Planetscale in 2026 is the right MySQL host for one specific shop: a high-write, schema-changes-weekly product team that has internalized the no-foreign-keys discipline and can absorb the $99-and-up monthly floor. Everyone else, including most early-stage SaaS, is better off on Neon, Supabase, or plain RDS.

We have been on Planetscale for just over two years. We came on during the hobby-tier era, lived through the April 2024 free-tier execution, made a deliberate call to stay, and have shipped about 400 schema migrations through it since. This is what the brochure does not tell you.

The April 2024 shock that frames everything

Planetscale killed the free Hobby plan on April 8, 2024. Existing hobby databases got two months to migrate or pay. The cheapest paid plan jumped from "free" to $39/month per database (the Scaler tier). For a team running dev, staging, and prod as separate databases, that was an instant $117/month line item where there had been zero.

The blast radius was bigger than the price. A generation of side-project tutorials, T3 stack starters, and "deploy your Next.js app" guides all assumed Planetscale Hobby. Theo Browne made a video about migrating off. Niall Maher wrote the canonical "here are the free alternatives" post. Neon and Supabase ran migration guides the same week. Planetscale itself eventually published its own migration guides for Aurora, Neon, and Supabase, which was a refreshingly honest move from a vendor watching customers walk.

We sat in a planning meeting that week and made the call: we are paying. Here is the math that decided it.

Why we stayed (the operator's case)

We had three things going for us that made the Scaler bill defensible:

1. We were already past the toy stage. ~30M rows in production, ~5M monthly row reads, schema changes every Tuesday.
2. We had built habits around branching and deploy requests that we did not want to give up.
3. Our app had no foreign-key enforcement at the database level anyway, because we had been on Planetscale long enough to internalize the workaround. Migrating to Postgres would mean adding constraints back, which is its own multi-week project.

If we had been earlier, point 3 would have flipped. A six-month-old codebase that still has REFERENCES clauses in the schema would migrate to Neon in a weekend and be happier for it.

The branching workflow is still the best feature on the market

This is the thing nothing else (yet) does as well. You create a dev-add-billing branch off main. You point your local app at that branch's connection string. You run schema changes against it. When you are ready to ship, you open a deploy request. Planetscale diffs the schema, runs the migration with online DDL, and merges. Production never locks.

We have run schema changes against tables north of 80M rows during business hours with zero customer-visible latency spike. The Vitess Online DDL machinery (Planetscale is built on Vitess, the same sharding layer YouTube uses) does the heavy lifting: it creates a shadow table, backfills it in chunks, switches reads, then drops the old. You do not have to think about pt-online-schema-change or gh-ost. It just works.

The competitors have caught up partway. Neon has branching, but it is copy-on-write at the storage layer, which is great for reads and slow when you start writing heavily to a long-lived branch. Supabase has branches now, but the migration story is more "run the SQL, hope for the best" than a managed online DDL. Aurora has fast clones, which is a different beast and not a workflow tool. Two years in, Planetscale's branching is still the one we miss most when we touch other systems.

One caveat: the 5-branch limit on the Scaler and Scaler Pro plans is real. If your team has more than four engineers shipping schema changes in parallel, you will hit it. The Enterprise tier removes the cap, but the price jump is severe.

The no-foreign-keys workaround you have to accept

Vitess does not enforce foreign keys when tables are sharded. Planetscale's stance has softened (FK constraints work on unsharded keyspaces in 2026), but the practical posture is still: do not rely on the database to enforce referential integrity. Treat it like the Stripe metadata column. The application owns the invariant.

In practice this means three things:

• Cascading deletes happen in the app, not in SQL. We use a before_destroy hook in our ORM that walks the dependency graph. We wrote it once two years ago and have rarely touched it.
• Orphan-row sweeps run as a nightly cron. Find rows whose parent_id no longer points at anything, log the count, alert if it spikes. We have caught two real bugs this way.
• Schema docs live in code. Without REFERENCES in the SQL, your ERD generator goes blind. We annotate models with explicit belongs_to :user, foreign_key_in_app: true and a Rake task generates the diagram from those.

Is this worse than database-enforced FKs? Yes. It is a real ergonomic tax. But it is also the price of admission to Vitess scaling, and once your team has the muscle memory it stops being a daily headache.

The pricing reality, one tier at a time

Here is the actual ladder we have walked, with what each step buys you.

Plan	Monthly cost	Storage	Row reads	Row writes	What it is for
Hobby (RIP)	$0	5 GB	1B	10M	Killed April 2024. Mourn briefly, move on.
Scaler	$39	10 GB	100M	50M	Smallest production database. Side projects with revenue.
Scaler Pro	$99 base + usage	100 GB included	metered	metered	Real production. Where most paying customers live.
Enterprise	$599+	negotiated	negotiated	negotiated	Multi-region, more than 5 branches, SLA, dedicated support.

The trap is not the headline price. It is the row-read meter on Scaler Pro. Every SELECT that touches a row counts. A poorly indexed query on a 10M-row table can chew through 100M reads in an afternoon. The first month we hit Scaler Pro, our bill was $147 because we shipped a feature with a missing composite index. We now run Planetscale's query insights tool every Friday and treat the top 10 most-expensive queries as a standing engineering ticket.

For comparison: Neon's $19 Launch plan and Supabase's $25 Pro plan both include far more headroom for the same money, because Postgres-on-disk pricing is fundamentally cheaper than metered Vitess. If your read volume is unpredictable and your team is small, this is the line that should make you reconsider.

When teams left, and when teams stayed

We watched a half-dozen peer companies make this call over the last two years. The pattern is clean.

Teams that left for Neon: Postgres-native shops that had bought Planetscale because of the branching and were willing to accept MySQL as a tax. Once Neon shipped real branching, they had no reason to stay. The migration was usually a long weekend with pgloader and a cutover script.

Teams that left for Supabase: Earlier-stage products that wanted auth, storage, and realtime in the same vendor. The database was rarely the deciding factor; it was the bundle. Worth reading our take on whether Supabase is the right backend for your SaaS if you are weighing the same trade.

Teams that left for Aurora: Bigger shops with an AWS commitment and a DBA on staff. They typically did not love Aurora; they loved that their VPC, IAM, and observability stack already lived in AWS. Aurora is the conservative choice, not the joyful one.

Teams that stayed on Planetscale: High-write MySQL workloads. Companies whose schema changes are weekly and load-bearing. Teams that had already built the no-FK habits and did not want to unbuild them. We are in this bucket.

If you are running an analytics-heavy read workload on a 50GB MySQL database with one schema change a quarter, Planetscale is the wrong tool and your bill will tell you so. If you are running a high-write product where deploy-request-driven migrations save you a real DBA hire, the math still works.

Schema-change ergonomics in real production

Two years of deploy requests has taught us a few things the docs do not emphasize.

Long migrations need foreman. A migration on a 60M-row table can run for six hours. Planetscale's UI shows progress, but you want a Slack bot that pings the channel every hour with % complete so the on-call engineer does not have to refresh a tab. We wrote ours in 80 lines.

The "revert" button is real and you will use it. In two years we have reverted maybe 8 deploy requests. Usually within an hour of merging, when query performance tanks because we forgot an index on the new column. The revert is fast and clean. Coming from systems where ALTER TABLE is a one-way door, this is genuinely calming.

Foreign-key-style joins still work; they just need indexes you set yourself. Without FK constraints, Planetscale will not auto-index your parent_id columns. Add the index in the same migration that adds the column or you will pay for it on the row-read meter the moment a customer scrolls a list view.

Branches go stale fast. A branch that lives more than 7 days will diverge enough from main that the deploy request gets ugly. We expire branches at 5 days now. Anything older gets deleted and re-created off fresh main.

The 2026 verdict: who Planetscale is right for

After two years of writing the checks, here is the honest matrix.

Buy Planetscale if you are:

• Running MySQL or Vitess at meaningful scale (>20M rows, >1M monthly writes)
• Shipping schema changes weekly or more
• A team of 2 to 8 engineers who can absorb the no-FK discipline
• Willing to spend $99-$300/month on database infrastructure as a real line item

Skip Planetscale if you are:

• A side project, MVP, or pre-revenue startup (the $39 floor is real and Neon's free tier exists)
• A Postgres-first shop (just use Neon, the branching is good enough)
• Read-heavy with predictable, low-frequency schema changes (Aurora or RDS is cheaper)
• Looking for an auth + storage + db bundle (Supabase wins)

We have no plans to leave. We have also stopped recommending Planetscale to every founder we mentor, the way we did in 2023. The audience for it is narrower now, and that is fine. A tool with a sharper edge is a better tool than one that pretends to fit everyone.

What to do this week

If you are evaluating Planetscale right now, do three things.

First, model your actual cost. Pull a representative day's SELECT count from your current database and multiply out. If you would burn through 100M row reads in a week, plan for Scaler Pro plus usage from day one, not the $39 floor.

Second, run a schema migration on a branch. The whole sales pitch is the deploy-request workflow. Spend 30 minutes branching, altering, and merging. If it does not feel meaningfully better than your current flow, the price is not worth it for you.

Third, talk to a senior engineer who has shipped on Vitess before. The no-FK discipline is the part most teams underestimate, and the people who have lived it can tell you in 20 minutes whether your codebase is ready. If you do not have that person on staff, every engineer on Cadence is AI-native by default and we maintain a small bench of senior database engineers with Vitess and Planetscale production experience; founders book a senior engineer at $1,500/week and get a 48-hour free trial to validate the migration plan before committing.

You can also run your current stack through our stack-grading tool for an honest take on whether Planetscale is the right edge of the wedge for your team or whether you would be better served by staying on Postgres.

Try it: If you are mid-migration and want a second opinion before you commit a weekend to pgloader, book a 48-hour trial with a senior database engineer on Cadence. Weekly billing, replace any week, no notice period. You leave with a migration plan you actually trust.

For the broader context on AI-native database work, our Supabase review for SaaS apps and best AI coding tools for senior engineers in 2026 cover the adjacent decisions most teams face at the same time.

FAQ

Is Planetscale worth $39/month?

Only if you have a production workload that benefits from MySQL, branching, and online DDL. For side projects and MVPs, Neon's free tier or Supabase's $25 Pro plan are better value. The $39 Scaler tier is genuinely a "real production database" floor, not a hobby tier in disguise.

Can I use foreign keys in Planetscale in 2026?

Sort of. Foreign key constraints work on unsharded keyspaces in 2026, but the production stance is still to enforce referential integrity in your application code. If FKs are a non-negotiable for your team, use Postgres on Neon or RDS instead.

How does Planetscale compare to Neon?

Neon is Postgres, Planetscale is MySQL/Vitess. Neon's branching is now competitive for read-heavy work and meaningfully cheaper at the low end. Planetscale wins for high-write workloads, frequent schema changes, and teams that need Vitess-class horizontal scaling. For most early-stage SaaS, Neon is the safer pick.

What killed Planetscale's free tier?

The Hobby plan was retired on April 8, 2024 because it did not pay for itself. Planetscale's leadership made the call to focus on paying production customers. Existing hobby databases got a two-month migration window. The cheapest plan since then is Scaler at $39/month per database.

Should I migrate from Planetscale to Neon in 2026?

Migrate if you are Postgres-first, your row-read bill exceeds $100/month, your schema changes are infrequent, or you do not need Vitess-scale horizontal sharding. Stay if you have a high-write MySQL workload, you ship schema changes weekly, and your team has internalized the no-foreign-keys discipline. The migration itself is usually a long weekend with pgloader, but the application-level cleanup (re-adding FK constraints, rewriting MySQL-isms) takes 2-4 weeks.