Migrate from PlanetScale to FoundryDB MySQL

PlanetScale removed its free tier in April 2024 and raised prices across the board, pushing many teams to re-evaluate their MySQL hosting. Beyond pricing, PlanetScale runs on Vitess, a sharding proxy that sits between your application and MySQL. While Vitess handles horizontal scaling well, it introduces compatibility quirks that can surprise you: no foreign key enforcement, limited support for certain joins, and behavior differences from native MySQL. If you want a standard MySQL experience with native replication, foreign keys, and no proxy layer, FoundryDB is a direct path forward.

This guide walks through exporting your database from PlanetScale and importing it into FoundryDB's native MySQL service. The process works for databases of any size, from small hobby projects to production workloads.

Why Migrate from PlanetScale?

PlanetScale built an impressive product on Vitess, but the tradeoffs are real:

• No foreign key enforcement. PlanetScale does not enforce foreign key constraints. Your application must handle referential integrity in code. This means bugs in your application logic can silently corrupt data relationships.
• Vitess compatibility gaps. Certain SQL features behave differently or are unavailable: some subquery patterns, specific JOIN operations, and DDL statements have restrictions. You are running "MySQL-like" rather than MySQL itself.
• Pricing increases. After removing the free tier, PlanetScale's Scaler plan starts at $39/month for 5 GB of storage. FoundryDB's tier-2 plan with 50 GB of NVMe storage offers more resources at a competitive price.
• Single engine. PlanetScale is MySQL-only. If your stack needs Redis-compatible caching, PostgreSQL for analytics, or Kafka for event streaming, you need additional providers.
• No GTID replication. PlanetScale uses Vitess-level replication rather than native MySQL GTID replication. This limits your ability to set up standard MySQL replicas or integrate with tools that expect GTID-based binlog positions.

FoundryDB runs native MySQL 8.4 with full foreign key support, GTID-based replication, ProxySQL connection pooling, and six additional database engines on the same platform.

Prerequisites

Before starting, make sure you have:

• PlanetScale CLI (pscale) installed and authenticated
• A FoundryDB account at foundrydb.com
• The fdb CLI installed (brew install foundrydb/tap/fdb or download from the dashboard)
• MySQL client tools available locally (mysqldump and mysql commands)

Step 1: Export Your Database from PlanetScale

PlanetScale provides a built-in dump command through its CLI:

pscale database dump my-planetscale-db main --output ./dump

This exports all tables from the main branch into individual SQL files in the ./dump directory. Each table gets its own file containing the schema and data.

Alternatively, if you prefer a single dump file, you can connect directly and use mysqldump:

# Get your PlanetScale connection string
pscale connect my-planetscale-db main --port 3309

# In another terminal, dump using mysqldump
mysqldump \
  --host 127.0.0.1 \
  --port 3309 \
  --user YOUR_PSCALE_USER \
  --set-gtid-purged=OFF \
  --no-tablespaces \
  --single-transaction \
  my_database > planetscale-dump.sql

The --set-gtid-purged=OFF flag is important because PlanetScale (Vitess) does not use standard MySQL GTID, so the dump should not include GTID metadata.

Step 2: Create a MySQL Service on FoundryDB

Provision a new MySQL instance:

fdb create \
  --database-type mysql \
  --version 8.4 \
  --plan-name tier-2 \
  --storage-size-gb 50 \
  --name my-mysql-db \
  --zone se-sto1

This creates a MySQL 8.4 instance with 2 vCPUs, 4 GB RAM, and 50 GB NVMe storage. Monitor provisioning:

fdb status my-mysql-db

Wait until the status shows Running. Provisioning typically takes 3 to 5 minutes.

Step 3: Get Your Connection Details

Retrieve your FoundryDB MySQL connection information:

fdb connect my-mysql-db --info

This shows the host, port, username, password, and connection URI. Note these values for the import step.

Step 4: Import Your Data

If you used the PlanetScale CLI dump (multiple files in a directory), import each file:

for f in ./dump/*.sql; do
  mysql \
    -h my-mysql-db-abc123.db.foundrydb.com \
    -u app_user \
    -pYOUR_PASSWORD \
    --ssl-mode=REQUIRED \
    defaultdb < "$f"
done

If you used a single mysqldump file:

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  defaultdb < planetscale-dump.sql

For large databases, you may want to disable key checks during import for better performance:

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  -e "SET GLOBAL foreign_key_checks=0; SOURCE planetscale-dump.sql; SET GLOBAL foreign_key_checks=1;" \
  defaultdb

Step 5: Update Your Application Connection Strings

Replace your PlanetScale connection string with the FoundryDB one:

mysql://app_user:YOUR_PASSWORD@my-mysql-db-abc123.db.foundrydb.com:3306/defaultdb?ssl-mode=REQUIRED

Most MySQL client libraries accept this URI format. For frameworks that use individual parameters:

# Example: Rails database.yml
production:
  adapter: mysql2
  host: my-mysql-db-abc123.db.foundrydb.com
  port: 3306
  username: app_user
  password: YOUR_PASSWORD
  database: defaultdb
  ssl_mode: required

Step 6: Verify the Migration

Connect and run verification queries:

fdb connect my-mysql-db

Or directly with the MySQL client:

mysql \
  -h my-mysql-db-abc123.db.foundrydb.com \
  -u app_user \
  -pYOUR_PASSWORD \
  --ssl-mode=REQUIRED \
  defaultdb

Run these checks:

-- Check all tables imported
SHOW TABLES;

-- Verify row counts on key tables
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'defaultdb'
ORDER BY table_rows DESC;

-- Verify foreign keys are enforced (this was impossible on PlanetScale)
SHOW CREATE TABLE orders;

-- Test a foreign key constraint
INSERT INTO orders (user_id, total) VALUES (999999, 10.00);
-- Should fail if user_id 999999 doesn't exist in users table

-- Check indexes
SHOW INDEX FROM your_main_table;

The foreign key test is the most important verification. On PlanetScale, the INSERT with a non-existent user_id would succeed silently. On FoundryDB's native MySQL, it correctly rejects the statement with a foreign key violation error.

What You Gain After Migrating

Switching from PlanetScale to FoundryDB gives you:

• Native MySQL, not a proxy. Your queries hit MySQL directly. No Vitess translation layer, no compatibility surprises. Standard MySQL documentation applies exactly as written.
• Foreign key enforcement. Referential integrity is handled by the database engine where it belongs. Remove the workarounds from your application code.
• GTID-based replication. FoundryDB uses standard MySQL GTID replication for read replicas and HA. This is compatible with the entire MySQL ecosystem of tools and monitoring.
• ProxySQL connection pooling. Enable the ProxySQL addon for intelligent query routing, connection multiplexing, and read/write splitting across replicas.
• 7 engines on one platform. Need Valkey for caching, Kafka for events, or PostgreSQL for a different service? Create them from the same dashboard and CLI. One bill, one set of credentials.
• Predictive autoscaling. FoundryDB monitors CPU, memory, storage, and connection trends, then scales resources proactively before your application feels the pressure.
• Point-in-time recovery. Continuous binary log archiving lets you restore to any second within your retention window. No more scheduled-snapshot-only recovery.
• EU infrastructure. All data stays in European data centers by default, simplifying compliance requirements.

The migration from PlanetScale is straightforward because you are moving from a MySQL-compatible system to actual MySQL. Your existing queries, ORMs, and tools will work without modification, and features that were restricted under Vitess (foreign keys, certain joins, subqueries) start working immediately.