PlanetScale Review: Living With Serverless MySQL
We migrated a mid-size application's database to PlanetScale specifically for the branching workflow, treating schema changes like git branches, after getting tired of coordinating manual migration windows with the rest of the team. Living with it in production since means I've got real opinions, and not all of them are the ones the marketing page leads with.
Database Branching Changed How We Ship Schema Changes
Creating a branch of the production database, making a schema change against it, and opening a deploy request that reviews the migration before merging it back is the feature that actually justified the switch. It brought schema changes into the same review workflow as code changes, catching a migration that would have locked a large table during business hours before it ever reached production, since a teammate reviewing the deploy request flagged it.
No More Manual Coordination for Non-Blocking Migrations
PlanetScale's non-blocking schema changes, handled automatically through the branch-and-deploy-request workflow rather than requiring us to hand-write an online schema change tool's invocation, removed a genuine operational burden. We used to schedule risky migrations for low-traffic windows and have someone on standby; that ritual mostly went away once the platform handled the online DDL mechanics itself.
The Free Tier Is Gone, and the Pricing Model Took Adjustment
PlanetScale removed its free Hobby tier in April 2024, and there's no free option to point a side project at anymore, only paid tiers starting around five dollars a month for a single-node, non-HA database aimed at development and low-traffic use, with production-grade high-availability clusters costing meaningfully more. Budgeting for a database from day one, even for a small internal tool, was an adjustment after years of defaulting to a free tier for anything low-stakes.
Postgres Support Is Newer Than the MySQL Side
We're running Vitess-based MySQL, which is PlanetScale's original and most mature offering, but the platform now also offers managed Postgres as a separate product line with its own branching workflow. I evaluated the Postgres option briefly for a new service and found it noticeably newer, fewer edge cases battle-tested compared to years of MySQL-on-Vitess in production across their whole customer base, which pushed us toward staying on MySQL for anything we actually depend on.
Foreign Key Support Has Real Limits
Vitess's sharding model historically didn't support foreign key constraints well, and while unsharded databases now have more complete support, this is worth checking against your specific schema before committing, especially if your data model leans on cascading deletes or complex referential integrity enforced at the database level rather than the application layer. We ended up moving some of that integrity logic into application code, which isn't inherently wrong but is extra surface area to get right.
Metered Billing Rewards Efficient Queries, and Punishes Sloppy Ones
Billing tied to rows read and written, on top of the base cluster cost, means an unoptimized query doing a full table scan shows up directly on the bill, not just in latency. This is a genuine incentive to write efficient queries that a flat-rate database doesn't give you, but it also means a bug that causes runaway querying, something we hit once with a retry loop that lacked backoff, has a cost dimension a flat-priced database wouldn't have surfaced as sharply.
Support and Documentation Held Up Under Real Incidents
The one production incident we've had, a connection pool exhaustion issue under a traffic spike, got a genuinely useful response from support within the timeframe our plan promised, and the documentation on connection limits and pooling recommendations was specific enough to actually fix the underlying configuration rather than just paper over the symptom.
Development Branch Hours Are a Budget Line You Have to Watch
Each database includes a set allotment of development branch hours per month, roughly the equivalent of a couple of always-on branches if you never spin them down. Leaving a development branch running idle over a long weekend out of forgetfulness ate into that allotment faster than expected the first month, and we've since made spinning branches down after use an actual team habit rather than an afterthought, since the platform doesn't do it for you automatically.
Comparing It Honestly Against Just Running Our Own MySQL
Before PlanetScale, we self-managed MySQL on a cloud VM, which was cheaper on paper but carried real operational cost, patching, backup verification, failover testing, that rarely showed up as a line item until something went wrong. The premium PlanetScale charges buys the branching workflow, but it also genuinely buys back the operational time we used to spend on database maintenance, and weighing the migration decision on database cost alone, without accounting for that operational time, would have undersold the actual case for switching.
Multi-Cloud Flexibility We Haven't Needed Yet, But Noted
PlanetScale runs across AWS, GCP, and Azure, and while we've stayed on a single cloud provider so far, that flexibility factored into the decision as insurance against a future infrastructure negotiation or a provider-specific outage, rather than something we're actively using today. It's the kind of feature that's hard to value precisely in advance but easy to appreciate in hindsight if the situation that needs it ever actually arrives.
Final Verdict
PlanetScale's branching workflow is a real, practical improvement to how schema changes get reviewed and shipped, and that alone justifies the migration for a team that's felt the pain of uncoordinated migrations before. The loss of a free tier and the newer, less proven state of the Postgres offering are the honest caveats: budget for it as a real line item from day one, and if you need Postgres specifically, go in expecting a less mature product than the MySQL side.
