PlanetScale Shutdown Aftermath: European MySQL Options in 2026

In April 2024, PlanetScale did the thing every infrastructure vendor swears it will never do: it killed the free tier. The "Hobby" plan — the one that had seeded tens of thousands of side projects, portfolio pieces, and bootstrapped startups — was given a short notice period and then shut off. Everyone who wanted to keep their database had to move to the Scaler plan at $39/month minimum, or migrate out.

For anyone who missed the timing: this happened two months after PlanetScale had already announced, in February 2024, that it was dropping active maintenance of the Vitess open-source project — the horizontally-sharded MySQL technology that was the entire technical premise of the product. A company that was once synonymous with Vitess quietly walked away from it, then killed the free onboarding ramp a few weeks later. The signal to developers was unambiguous: we are not the company you thought we were, and we are not the price you thought we were.

It is now 2026. The dust has settled. Teams have moved. Nobody is writing Medium posts about PlanetScale anymore because the interesting choice is no longer "PlanetScale vs the world" — it is "what should the world have been using all along." This post is the honest aftermath: where the refugees went, how much the pricing shock actually cost real teams, and the European MySQL and MariaDB options that make sense now, in 2026, for EU companies who learned the hard way that US-based serverless databases are not a free lunch.

What Actually Happened (A Short Timeline)

• February 2024: PlanetScale announces it will no longer actively maintain the open-source Vitess project. Community maintainers take over, but velocity drops. The CNCF status of the project becomes a lot more complicated.
• April 2024: PlanetScale kills the free Hobby tier. Existing Hobby databases are given a deadline to upgrade or be deleted. The new entry price is Scaler Pro at $39/month, with per-row read/write metering on top.
• Mid-2024: Mass migration event. Teams dump databases with mysqldump and pscale database dump, and move to Aurora, RDS, Neon (after schema conversion), Supabase, Railway, or bare managed MySQL on a European cloud.
• Late 2024 - 2025: PlanetScale pivots toward the enterprise "Postgres + managed Vitess" market. The self-serve developer audience is effectively gone.
• 2026: The question "what is the cheapest PlanetScale-like thing?" has been replaced by "why did I ever need PlanetScale in the first place?" for most teams.

The lesson, in retrospect, was not really about PlanetScale — it was about the asymmetry between what a serverless database vendor sells you and what your application actually needs. Most applications never needed Vitess. They needed a managed MySQL that took care of backups, replicas, and TLS certs. The branching feature was delightful, but it was solving a problem most teams solved differently anyway. And the per-row metered billing that replaced the flat Hobby tier was the kind of pricing that punishes you for being successful.

The Pricing Shock, Quantified

When the Hobby tier died, a typical side-project user went from $0/month to $39/month minimum, plus metered reads and writes. If your app had any real traffic, the bill could easily creep to $60-$120/month, and at that point you were paying more for a database than for the VPS running your whole stack.

Here is what teams were actually looking at, in round numbers:

The uncomfortable part is that a flat managed MySQL on a European provider starts at €19.99/month and includes the replicas, backups, and TLS certs you were paying extra for on PlanetScale. The math for almost every non-enterprise customer stopped making sense overnight.

The Vitess Story (and Why It Barely Mattered)

The emotional core of the PlanetScale pitch was always Vitess: the horizontally-sharded MySQL layer that YouTube built, Slack ran on, and PlanetScale commercialized. The promise was "MySQL that scales like Cassandra." That is a genuinely impressive piece of engineering.

But here is the uncomfortable truth the 2024 exodus revealed: the overwhelming majority of PlanetScale customers never needed Vitess. They needed MySQL with good operational ergonomics — backups that work, replicas that fail over, schema changes that do not lock the table. They did not need 100 TB of transparent sharding. They needed an on-call team they did not have to hire.

This is why, when the prices went up and the Vitess project entered community-maintenance mode, most refugees did not flee to another sharded MySQL. They went back to flat, single-instance managed MySQL — Aurora, RDS, Cloud SQL, or a European managed MySQL provider. The horizontal sharding was never the load-bearing feature; it was the marketing.

For the tiny minority that genuinely does need sharded MySQL, the options today are:

• TiDB Cloud / TiDB Serverless — MySQL-compatible distributed SQL, actively developed, with a real serverless free tier. This is where serious sharding workloads went.
• Self-hosted Vitess on Kubernetes — for teams with the operational capacity. Vitess still works; it is just not commercially championed anymore.
• Application-level sharding — which is what almost everyone does anyway once they hit real scale, because it gives you control PlanetScale never did.

If you are reading this and you are not sure whether you are in the "needs sharding" minority: you are not. If you were, you would know.

The CLOUD Act Problem Nobody Talked About in 2023

One of the less-discussed aspects of the PlanetScale migration was the data sovereignty realization. PlanetScale is a US company. Even if you picked their EU region, your database provider was subject to the US CLOUD Act, which gives US federal authorities the legal right to compel data disclosure from US-based companies regardless of where the data physically sits. For European businesses, this is a GDPR issue even when the bytes never leave Frankfurt.

In 2024-2025, EU regulators, DPAs, and auditors started asking harder questions about this. "Your data is in the EU" stopped being an acceptable answer when the operator was in the US. For SaaS companies selling into regulated industries (health, finance, public sector, education), the combination of Schrems II, GDPR Article 44, and the CLOUD Act made a US-operated database a growing compliance risk.

This shifted the post-PlanetScale conversation in Europe. The question was no longer just "what is the cheapest managed MySQL" — it was "what is the cheapest managed MySQL operated by an EU company, in an EU datacenter, under EU-only legal jurisdiction". That is a meaningfully smaller list.

Where Everyone Actually Went: The Post-Shutdown Landscape

Two years of observed migrations later, here is the honest map of where PlanetScale users ended up. No affiliate pretense — just what the actual traffic patterns and community threads show.

Two observations jump out of that table. First, the EU-operated managed MySQL options are meaningfully cheaper than PlanetScale's post-shutdown pricing — in some cases 50-70% cheaper for equivalent workloads. Second, the one feature that is genuinely hard to replace — native branching — is only preserved by TiDB Cloud and Neon (Postgres). Every other option re-approaches that problem through a CI/CD workflow, and for most teams that turns out to be fine.

The EU-Focused Options, Honestly Compared

DanubeData Managed MySQL and MariaDB

DanubeData is a European managed cloud provider operating from Falkenstein, Germany. It offers flat-priced managed MySQL (versions 8.0, 8.4, 9.0, 9.1) and MariaDB (10.11 through 11.6) starting at €19.99/month, with read replicas, SSL/TLS, automatic backups, and per-minute billing.

The MariaDB option is worth calling out explicitly. MariaDB was forked from MySQL by the original MySQL author when Oracle bought Sun, and for the overwhelming majority of applications it is a drop-in replacement: same wire protocol, same SQL dialect, same client libraries, same tools. If you were on PlanetScale MySQL, you can almost certainly land on DanubeData MariaDB without code changes — and MariaDB's online DDL support is notably better than MySQL's, which partially replaces what PlanetScale's non-blocking schema changes used to do.

DanubeData-specific strengths for post-PlanetScale refugees:

• Flat pricing — €19.99/mo is €19.99/mo. No per-row read/write metering. Your bill does not spike when your app has a good day on Hacker News.
• EU-operated — the company is European, the datacenter is in Germany, the legal jurisdiction is EU-only. CLOUD Act does not apply.
• Read replicas included on all plan sizes, with reader endpoints for load-balanced replica access.
• Automatic backups — daily snapshots on TopoLVM, fast LVM-based restore, no manual pg_dump cron.
• €50 signup credit — enough to run a Starter plan for over two months while you migrate and evaluate.

Aiven for MySQL

Finnish company, genuinely EU-operated, available across multiple EU datacenters. Aiven is the enterprise-friendly option: polished UI, good observability, strong compliance story. Pricing starts higher than DanubeData (the cheapest Business-4 tier lands around €70/month), which reflects the target audience — Aiven is for teams that would also buy Confluent Cloud. For a small SaaS or side project, it is overkill. For a Series A company that wants a "safe" EU vendor, it is a defensible pick.

Scaleway Managed Database

French, EU-operated, competitively priced. The DEV1-S tier starts around €13/month. Scaleway's managed database product is functional and cheap, but it has historically been rougher around the edges than Aiven or OVHcloud on observability and support response. It is a strong pick if you are already in the Scaleway ecosystem.

OVHcloud Managed MySQL

French, the largest European cloud provider, strong GDPR story. OVHcloud's managed MySQL is boring in the best sense — it works, the pricing is predictable (~€15/mo entry), and OVH has been around long enough that you can trust it is not going to pull a PlanetScale. The UI is functional rather than delightful.

What About Neon, Crunchy, or Supabase?

All three are Postgres-only. If you are willing to migrate from MySQL to Postgres (and many post-PlanetScale teams did), Neon is the closest thing to PlanetScale's branching experience. But if MySQL is non-negotiable — because of your ORM, your team's expertise, or existing MySQL-specific features — these are not on the list.

TiDB Cloud: The Genuine Vitess Replacement

TiDB is MySQL wire-protocol-compatible but is actually a distributed SQL database under the hood (HTAP, Raft-based, horizontally sharded). It is the closest thing to "PlanetScale but still developing." It has a real free serverless tier and native branching. For the small minority of teams that genuinely needed Vitess-scale, TiDB Cloud is the right answer. For everyone else it is overkill and operationally heavier than a flat managed MySQL.

Replacing PlanetScale Features Without PlanetScale

Three PlanetScale features drove the product's appeal: database branching, non-blocking schema changes, and transparent sharding. Here is how to reconstruct each one on a flat managed MySQL (or MariaDB) in 2026.

Branching: GitHub Actions + Ephemeral Databases

PlanetScale's branching was: "for every PR, get an isolated copy of the schema, run migrations, and merge the schema changes back to main." This is a workflow, not a database feature. You can replicate it in GitHub Actions with a throwaway DanubeData instance per PR.

# .github/workflows/pr-database.yml
name: Preview Database per PR

on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

jobs:
  create-preview-db:
    if: github.event.action != 'closed'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Create ephemeral MySQL via DanubeData API
        env:
          DD_TOKEN: ${{ secrets.DANUBEDATA_API_TOKEN }}
        run: |
          curl -X POST https://danubedata.ro/api/v1/databases 
            -H "Authorization: Bearer $DD_TOKEN" 
            -H "Content-Type: application/json" 
            -d '{
              "name": "pr-${{ github.event.pull_request.number }}",
              "provider": "mysql",
              "version": "8.4",
              "plan": "starter",
              "expires_in_hours": 48
            }'

      - name: Load production schema snapshot
        run: |
          mysqldump --no-data -h $PROD_HOST -u $PROD_USER -p$PROD_PASS main_db > schema.sql
          mysql -h $PREVIEW_HOST -u $PREVIEW_USER -p$PREVIEW_PASS pr_db < schema.sql

      - name: Run migrations
        run: |
          npm run migrate -- --database-url=$PREVIEW_URL

      - name: Run tests against preview DB
        run: npm test -- --database-url=$PREVIEW_URL

  teardown-preview-db:
    if: github.event.action == 'closed'
    runs-on: ubuntu-latest
    steps:
      - name: Delete ephemeral DB
        run: |
          curl -X DELETE https://danubedata.ro/api/v1/databases/pr-${{ github.event.pull_request.number }} 
            -H "Authorization: Bearer $DD_TOKEN"

This is not as elegant as pscale branch create, but it does the same job, it is cheap (the ephemeral database costs cents for 48 hours of wall-clock time), and it is under your control. And because DanubeData bills per minute, a PR database that lives for 3 hours costs a few cents, not a day's worth of quota.

Non-Blocking Schema Changes: gh-ost and pt-online-schema-change

PlanetScale's "deploy without downtime" feature for schema changes was the polished UI on top of a well-known underlying technique: rewrite the table into a shadow copy, stream writes via triggers or binlog, and atomically swap. There are two excellent open-source tools that do this for plain MySQL/MariaDB:

• gh-ost — GitHub's online schema tool, uses the binlog stream for changes, no triggers on the source table. This is the modern choice.
• pt-online-schema-change — Percona's older tool, uses triggers. Works fine, widely deployed.

# gh-ost example: add a column to users table with zero downtime

gh-ost 
  --host=db-xxxxx.danubedata.ro 
  --port=3306 
  --user=migrator 
  --password=$DB_PASS 
  --database=myapp 
  --table=users 
  --alter="ADD COLUMN email_verified_at DATETIME NULL" 
  --allow-on-master 
  --switch-to-rbr 
  --chunk-size=1000 
  --max-load=Threads_running=25 
  --critical-load=Threads_running=1000 
  --execute

On MariaDB, you also get a third option: native online DDL with ALTER ... ALGORITHM=INPLACE, LOCK=NONE. For many common operations (adding nullable columns, adding indexes concurrently, etc.) MariaDB can do the schema change online without any external tool. This is one of the reasons MariaDB is a strong PlanetScale replacement — the feature that made PlanetScale feel special is partly just built in.

Sharding: Honestly, You Probably Do Not Need It

If you have spent the last section reading about GitHub Actions CI databases and gh-ost, and nothing has set off a "but what about our 50 TB of shards" alarm, then you can skip this section. Most apps fit comfortably on a single large managed MySQL instance for far longer than founders expect. The DanubeData Business plan gives you 4 vCPU, 8 GB RAM, 100 GB storage for €79.99/month, and that is enough for multiple millions of rows and thousands of queries per second.

If you genuinely are approaching limits that need horizontal sharding, your options are:

• TiDB Cloud — managed, MySQL-compatible, the cleanest path.
• Self-host Vitess on Kubernetes — DanubeData runs a k3s-based platform, and Vitess Operator on a dedicated k3s cluster gives you exactly what PlanetScale was selling, minus the sunset risk. This is a big operational lift; only do it if Vitess is truly the answer.
• Application-level sharding — split users by tenant ID or hash into N separate databases. Harder to write, but gives you total control and scales linearly with managed database instances.

Migration Playbook: PlanetScale to DanubeData

The actual migration is mechanically simple. The hard part is the cutover window, not the data movement. Here is the full playbook.

Step 1: Dump from PlanetScale

# Option A: the PlanetScale CLI (recommended — handles Vitess quirks)
pscale database dump myapp-db main --output ./psdb-dump

# Option B: mysqldump against the PlanetScale connection
mysqldump 
  --host aws.connect.psdb.cloud 
  --user your_user 
  --password 
  --set-gtid-purged=OFF 
  --no-tablespaces 
  --single-transaction 
  --routines 
  --triggers 
  myapp_db > psdb-dump.sql

# If your schema uses features PlanetScale silently rewrote
# (e.g. foreign keys were disabled by default), you may need
# to manually add CONSTRAINT clauses after dumping.

Step 2: Provision DanubeData MySQL (or MariaDB)

# Via the DanubeData dashboard:
#   1. Log in at https://danubedata.ro
#   2. Click "Create Database Instance"
#   3. Pick MySQL 8.4 (or MariaDB 11.4 for MySQL compatibility)
#   4. Pick plan: Starter (€19.99) to Business (€79.99)
#   5. Enable a read replica if you need one (takes 2 minutes)
#   6. Grab the connection details from the dashboard

# Via the DanubeData API:
curl -X POST https://danubedata.ro/api/v1/databases 
  -H "Authorization: Bearer $DD_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "name": "myapp-production",
    "provider": "mysql",
    "version": "8.4",
    "plan": "standard",
    "replicas": 1,
    "backup_retention_days": 7
  }'

Step 3: Import the Dump

# Download the DanubeData TLS bundle from the dashboard
# (saved as ca.pem for SSL verification)

mysql 
  --host=db-xxxxxx.danubedata.ro 
  --user=myapp 
  --password 
  --ssl-ca=ca.pem 
  --ssl-mode=VERIFY_IDENTITY 
  myapp_db < psdb-dump.sql

# If the dump is large, consider mysqlpump or parallel restore
# to keep the window short:
mysqlpump --parallel-schemas=4 ...

Step 4: The Cutover

For a zero-downtime migration, the pattern is:

1. Snapshot and load — take a consistent mysqldump, load into DanubeData. Note the binlog position.
2. Logical replication — configure PlanetScale as the source and DanubeData as the replica, replaying binlog from the recorded position. PlanetScale exposes a binlog-compatible stream; if you hit Vitess-specific edge cases, tools like mysql-binlog-connector-java or Debezium can mediate.
3. Switch reads first — update half your read traffic to the DanubeData endpoint. Watch for replication lag and application errors.
4. Freeze writes, drain lag, switch writes — brief write freeze (10-60 seconds), wait for DanubeData to catch up to the last binlog event, flip the DATABASE_URL, unfreeze.
5. Decommission PlanetScale — keep it read-only for 48 hours as a rollback option, then delete.

For a simpler migration with a short maintenance window (most real migrations), you can skip logical replication entirely: pick a low-traffic window, set the app to maintenance mode for 5-15 minutes, run the dump + import, flip DATABASE_URL, and go.

Step 5: Update Connection Strings

# Before (PlanetScale):
DATABASE_URL="mysql://user:pass@aws.connect.psdb.cloud/myapp_db?sslaccept=strict"

# After (DanubeData MySQL):
DATABASE_URL="mysql://user:pass@db-xxxxxx.danubedata.ro:3306/myapp_db?ssl-mode=VERIFY_IDENTITY&ssl-ca=/app/ca.pem"

# After (DanubeData MariaDB — often a drop-in replacement):
DATABASE_URL="mysql://user:pass@db-xxxxxx.danubedata.ro:3306/myapp_db?ssl-mode=VERIFY_IDENTITY&ssl-ca=/app/ca.pem"

# Prisma note: Prisma works against both MySQL and MariaDB
# with the mysql provider. No schema.prisma change needed.

Cost Comparison: Two Years Later

Concrete numbers for a real-world SaaS, three years running, post-migration:

The typical pattern over the two years after migration: teams initially provisioned a larger DanubeData instance than they needed (out of caution), then right-sized down once they had real observability on their actual workload. The final 2026 steady-state cost for most small SaaS refugees is €19.99/month — about half of what PlanetScale Scaler Pro costs, with full EU sovereignty.

Frequently Asked Questions

Do I lose database branching by migrating away from PlanetScale?

Native branching, yes. Functional branching, no. The GitHub Actions + ephemeral database pattern described above replicates the per-PR-database workflow for a few cents per PR. For most teams, this is actually preferable because the ephemeral database matches your production version exactly, runs your real migrations, and tears down automatically. If you want native branching and you are willing to switch engines, Neon (Postgres) has it; TiDB Cloud (MySQL-compatible) has it.

Is MariaDB really a drop-in replacement for MySQL?

For the overwhelming majority of applications, yes. MariaDB was forked from MySQL 5.5 by the original MySQL author and has maintained wire-protocol and SQL-dialect compatibility. Prisma, Sequelize, TypeORM, ActiveRecord, SQLAlchemy, GORM, and Doctrine all work against MariaDB with the MySQL driver. The edge cases where you would notice a difference are: some Oracle-authored MySQL 8 features (CHECK constraints work differently, JSON internal representation differs, certain window functions have different optimizer behavior). If your app is not doing anything exotic with those features, you can switch today.

How do I do online schema changes without PlanetScale's UI?

Three paths. On MySQL, use gh-ost (the current best-practice tool from GitHub) or pt-online-schema-change (Percona's older but battle-tested tool). On MariaDB, try native online DDL first (ALTER ... ALGORITHM=INPLACE, LOCK=NONE) — it covers a large fraction of common operations including adding columns and indexes without blocking writes. For the operations that still need a shadow-copy approach, fall back to gh-ost, which also works on MariaDB.

Does DanubeData support read replicas like PlanetScale did?

Yes. All DanubeData managed database plans support adding read replicas, with a separate reader endpoint that load-balances across replicas. You add them from the dashboard or via the API, and the replica is provisioned and streaming in a few minutes. Pricing is per-replica at the same plan size.

Is DanubeData GDPR-compliant? What about the CLOUD Act?

DanubeData is a European company operating exclusively from a German datacenter in Falkenstein, with EU-only legal jurisdiction. It is not subject to the US CLOUD Act because the company is not a US company. The platform is GDPR-compliant by design — EU-only data storage, standard SCC-free data processing (because there is no US transfer), and a signable DPA. For regulated industries (health, finance, public sector), this is meaningfully different from a US-operated database vendor with an "EU region."

How much downtime does a PlanetScale migration take?

With the simple cutover approach (maintenance window): typically 5-15 minutes for databases under 50 GB. With logical replication and read/write traffic shifting: effectively zero (seconds of write freeze). The determining factor is dump + import time, which on NVMe-backed DanubeData storage and a modern network link is bounded mostly by the size of the largest single table. Plan for 1 GB/minute as a conservative baseline.

Do I have to rewrite my application code?

In 99% of migrations, no. The connection string changes and the TLS certificate bundle changes. That is it. PlanetScale's Vitess layer sometimes silently disabled features (foreign keys, transactions across shards), so when you move to real MySQL those features become available again — which is a strict upgrade, not a regression. The only cases that need code changes are apps that explicitly used Vitess-specific pragmas or PlanetScale CLI tooling inside the app, and those are rare.

Should I move to Postgres while I am migrating anyway?

Only if you have a specific reason to. Moving engines adds a significant schema-conversion step (AUTO_INCREMENT becomes IDENTITY, TINYINT(1) becomes BOOLEAN, DATETIME becomes TIMESTAMP, JSON semantics differ) and the potential for ORM-level issues. If your app works fine on MySQL, staying on MySQL (or switching to MariaDB) is cheaper, faster, and less risky. If you were already thinking about Postgres for its JSONB, CTEs, or extensions, a migration is a reasonable forcing function — but do not do it just because Postgres is fashionable in 2026.

The Honest Recommendation

If you are reading this in 2026 because you are still on PlanetScale and the bill keeps surprising you: migrate to a flat managed MySQL on a European provider and save 50-70%. For teams under a few dozen GB of data and a few thousand queries per second, DanubeData Managed MySQL at €19.99/month is the direct replacement for what Scaler Pro used to be, with EU operation, full GDPR compliance, and no metered billing surprises.

If you genuinely have a sharded-workload problem that Vitess was solving for you — and you are sure about that — look at TiDB Cloud or self-hosted Vitess. But be honest about whether you are in that category. Two years of post-shutdown migration data suggests that almost nobody was.

The broader lesson, beyond any specific vendor choice, is that the flashy serverless-database pitch of the early 2020s did not hold up. The teams that quietly stayed on boring managed MySQL — or moved to it after getting burned — ended up with cheaper bills, fewer surprises, and databases they could reason about. In 2026, boring is the new exciting.

Get Started on DanubeData

If you want to try the migration path described in this post:

1. Create a Managed MySQL or MariaDB database — starts at €19.99/month, includes replicas and backups.
2. Claim the €50 signup credit — that is over two months of Starter runtime free while you migrate and evaluate.
3. Dump your PlanetScale database with pscale database dump or mysqldump and import it using the instructions above.
4. Update your DATABASE_URL, download the TLS CA bundle, and point your app at the new host.

DanubeData Managed Database features at a glance:

• MySQL 8.0, 8.4, 9.0, 9.1 — and MariaDB 10.11 through 11.6 — and PostgreSQL 15 through 17
• Read replicas on every plan, with a load-balanced reader endpoint
• Automatic daily backups with fast LVM-based restore
• SSL/TLS certificates provided and managed
• German datacenter (Falkenstein), EU-only legal jurisdiction, CLOUD-Act-free
• Flat monthly pricing, per-minute billing, no per-row metering
• Free migration assistance if you are coming from PlanetScale, Aurora, or RDS

👉 Create Your Managed Database — from €19.99/month

Migrating a larger workload from PlanetScale and want a second pair of eyes on the cutover plan? Talk to the DanubeData team — we have done this migration enough times in 2024-2025 that we will tell you exactly where the sharp edges are.