Why PlanetScale’s Free Tier Exit Forces a Harder Look at MySQL-Compatible Managed Database Costs
This is not a best-of list. Those answer a question you didn’t ask. What you need is a decision framework for a specific event: PlanetScale retired its Hobby plan, and if you were running a free database there, you now face a forced migration or a first paid bill. The “best” database depends on which constraint actually binds your team.
Step 1: Deconstruct Your Actual Situation
Before comparing logos, map your real parameters:
| Factor | Questions to Answer |
|---|---|
| Team size | Are you solo, a small product team, or an org with dedicated platform engineers? |
| Budget ceiling | Is any paid database spend pre-approved, or are you defending a new line item? |
| Compliance regime | Do you need SOC 2, HIPAA, or GDPR-specific data residency now, or is that future-you’s problem? |
| Existing stack | Is your application already MySQL-native, or did you choose PlanetScale for the workflow, not the wire protocol? |
| Operational headcount | Who wakes up if the primary fails at 3 a.m.? |
Most teams landing on this article share a profile: small to medium, cost-sensitive, possibly with a side project that grew production traffic, and now facing a pricing shock they didn’t model.
Step 2: Segment Into Sub-Decisions
The PlanetScale Hobby deprecation forces five distinct decisions, not one:
- MySQL compatibility need — Does your application require MySQL specifically, or can you port to PostgreSQL?
- Horizontal scaling need — Do you actually need Vitess-style sharding, or would a single-node managed instance suffice?
- Free-tier dependency — Is zero database spend a hard requirement, or can you absorb a modest monthly minimum?
- Egress/ingress cost structure — How does data transfer pricing compare across your shortlist?
- Operational headcount — Can you self-manage, or do you need the vendor to own uptime?
Step 3: Diagnose the Actual Bottleneck
For most teams post-deprecation, the bottleneck is not technical. It is free-tier dependency colliding with workflow lock-in.
PlanetScale’s schema deployment workflow (deploy requests, branching, safe migrations) became the reason teams stayed, not the MySQL protocol itself. When the vendor’s official changelog states the Hobby plan was deprecated on April 8th, 2024, with new Hobby databases blocked from creation as of March 6th, 2024, teams lost the ability to evaluate that workflow for free. The vendor’s official changelog notes that remaining Hobby databases were slept and require upgrade to the Base plan or manual wake to access data.
The emotional and technical cost of learning a new migration workflow often exceeds the dollar cost of the replacement database. This is the bottleneck: not whether pricing varies by plan, but whether you are willing to relearn operations for a different platform’s model.
Step 4: Prescribe Specific Paths
Here are three concrete paths, each with a named trade-off and a clear “wrong for” profile.
Path A: Stay with PlanetScale, Accept Resource-Based Pricing
PlanetScale’s current entry point is the Base plan, which the vendor’s official pricing page describes as resource-based pricing without fixed tier names, allowing upsize and downsize of instances as needed. The vendor’s official changelog indicates this replaced the previous Scaler plan structure. The vendor’s official pricing page also lists PlanetScale Postgres from $5/month as a separate offering.
Trade-off accepted: You pay for operational workflow continuity. You do not get predictable fixed pricing; costs scale with resource consumption.
Who this is wrong for: Teams with hard monthly budget caps who cannot tolerate variable bills. Teams whose usage patterns spike unpredictably and who lack cost alerts configured. Teams who chose PlanetScale primarily because it was free and never deeply adopted the branching workflow.
Path B: Migrate to Supabase, Absorb PostgreSQL Porting Cost
Supabase presents the strongest structural alternative for teams willing to exit MySQL. The vendor’s official pricing page states that paid plans come with $10/month in compute credits to cover one Micro instance or offset other instance costs. The vendor’s official documentation notes that each project increases monthly compute costs, with hourly charging for additional compute based on usage. Published third-party benchmarks report Supabase Pro at $25/month per project with 8 GB database as a comparison point for teams considering a Postgres alternative.
Visit Supabase’s official site
Trade-off accepted: You port schema, queries, and possibly ORM configurations to PostgreSQL. You gain a bundled ecosystem (auth, storage, edge functions) but lose MySQL-specific tooling and the Vitess scaling path.
Who this is wrong for: Teams with deep MySQL optimization (custom engine settings, binary log consumers, MySQL-specific replication topologies). Teams who need horizontal sharding now or imminently—Supabase scales vertically on a single Postgres instance, with read replicas as the primary scaling mechanism. Teams with multiple microservices each needing isolated databases; per-project pricing accumulates fast.
Path C: Move to DigitalOcean Managed Databases, Self-Manage More
DigitalOcean offers a self-host-adjacent managed option. The vendor’s official pricing page indicates managed databases deploy onto Droplets with shared or dedicated CPU options. Published third-party benchmarks reference managed MySQL pricing that starts in the range of $15 per database cluster. The vendor’s official documentation notes that beginning October 15, 2026 for new accounts and November 30, 2026 for all accounts, new Standard Edition clusters cannot use plans with more than 4 GiB of RAM or add standby or read-only nodes.
Visit DigitalOcean’s official site
Trade-off accepted: You accept more operational responsibility for backups, patching schedules, and scaling events. You gain predictable infrastructure pricing and direct Droplet access. You lose the serverless abstraction and automatic scaling.
Who this is wrong for: Teams without anyone who can reason about Linux, disk I/O, or connection pooling. Teams who need global multi-region deployment (DigitalOcean’s regions are fewer than AWS/GCP/Azure). Teams who expect to exceed 4 GiB RAM on Standard Edition after the 2026 plan changes. Teams who valued PlanetScale’s zero-downtime schema changes; DigitalOcean managed databases do not provide equivalent built-in branching.
Cost Structure Comparison
| Dimension | PlanetScale Base | Supabase Pro | DigitalOcean Managed MySQL |
|---|---|---|---|
| Entry pricing model | Resource-based, variable | $25/month per project + compute credits | Fixed infrastructure tiers |
| Free tier | None (Hobby deprecated April 2024) | Available with limits | None for managed databases |
| Protocol | MySQL / Postgres | PostgreSQL | MySQL, PostgreSQL |
| Scaling model | Horizontal (Vitess) / Vertical | Vertical + read replicas | Vertical, manual node addition |
| Best fit | Workflow-dependent MySQL teams | Full-stack teams wanting bundled services | Infrastructure-savvy teams wanting predictability |
Security Applicability Note
This article addresses cost and operational structure, not security architecture. Database encryption at rest, network isolation, and access control configurations vary by vendor and change with feature releases. What satisfies SOC 2 Type II for one team may not satisfy your auditor’s interpretation. This is not security advice; evaluate controls against your compliance regime directly.
The Harder Look You Were Avoiding
PlanetScale’s Hobby deprecation did not create a database cost problem. It surfaced one that was already latent: free tiers obscure true total cost of ownership, and workflow lock-in is the most expensive dependency of all.
If you are a solo developer with no revenue, the honest answer is that managed databases may be premature. Consider whether your project has outgrown SQLite or a single container with persistent volume. If you are a team with production revenue, the modest monthly range is not your risk; the risk is choosing based on yesterday’s free tier rather than tomorrow’s scaling model.
The prescription: audit your actual MySQL dependency. If it is protocol-deep, stay in the MySQL ecosystem and price-shop between PlanetScale Base and DigitalOcean with eyes open to the 2026 plan restrictions. If it is workflow-shallow, the Supabase porting cost pays back in ecosystem breadth. Name your trade-off explicitly. Anything else is a decision deferred, not a decision made.
