Migrate from PlanetScale to Swyftstack.
One caveat up front: PlanetScale is MySQL, Swyftstack is PostgreSQL. We tell you when it's clean and when it's not.
This is usually painless if…
- Your app uses an ORM (Prisma, Drizzle, TypeORM, Sequelize, Knex)
- Your schema uses standard SQL types
- You don't depend on MySQL-specific syntax
This requires more work if…
- You have stored procedures or triggers written for MySQL
- You use MySQL-specific functions in queries
- You depend on PlanetScale's branching workflow extensively
How a PlanetScale → Swyftstack migration works
Via PlanetScale's tools, or our migration helper.
Most types map directly. We flag anything that doesn't and ask you to confirm.
Tables, indexes, sequences - verified end-to-end.
Change the database driver, swap provider = "mysql" for "postgresql" if you're on Prisma, regenerate, redeploy.
Where the engine change actually bites
Four types need a decision
Most types map directly. The exceptions: TINYINT(1) becomes a real BOOLEAN, AUTO_INCREMENT becomes SERIAL or IDENTITY, unsigned integers have no equivalent (use a wider signed type plus a CHECK), and zero-dates like 0000-00-00 must be cleaned because Postgres rejects them.
Foreign keys become enforced
PlanetScale runs on Vitess, which does not enforce foreign keys at scale, so orphaned rows can accumulate unnoticed. Postgres enforces them for real. Validate referential integrity in staging during the dry run so you fix orphans deliberately, not on your first production write.
Case sensitivity flips
MySQL collations are case-insensitive by default, so Alice and alice match. Postgres is case-sensitive. If logins or search rely on case-insensitive matching, use the citext extension or LOWER() with an expression index. Skipping this is the classic works-in-dev, breaks-for-one-user bug.
Branching becomes migration files
You lose PlanetScale's branch and deploy-request workflow. You gain schema changes as migration files in your repo, reviewed in the same pull request as the code. Pair Prisma Migrate, Drizzle, or Atlas with a staging database for reviewable, rollback-aware changes.
Frequently asked
Why no MySQL on Swyftstack?
V1 is PostgreSQL-only. PostgreSQL has stronger transactional guarantees, richer indexing (partial, expression, GIN/GiST), and a deeper extension ecosystem (PostGIS, pgvector, pg_trgm) for the workloads we care about most. We'd rather do one engine extremely well than two adequately.
Will my Prisma schema convert cleanly?
Usually yes. Booleans, enums, indexes, and foreign keys all translate. The one thing to know: PlanetScale disables foreign-key constraint enforcement by default, so your Prisma schema may declare relations your old database never actually enforced. On Postgres those constraints are real, which can surface orphaned rows that were always there. We flag this before cutover so it's never a surprise.
Should I rewrite my queries?
Most ORM queries don't change at all. Raw SQL needs minor edits: backtick identifiers become double quotes, LIMIT/OFFSET is identical, but MySQL string and date functions (e.g. IFNULL, DATE_FORMAT, GROUP_CONCAT) map to Postgres equivalents (COALESCE, to_char, string_agg). We give you a checklist of the exact functions in your codebase that need attention.
What replaces PlanetScale branching?
PlanetScale's branch + deploy-request workflow is genuinely good for schema changes. On Postgres the equivalent is a migrations tool (Prisma Migrate, Drizzle, Atlas, or Flyway) plus a staging database. You lose the branch UI; you gain version-controlled, reviewable migration files that live in your repo.
I rely on Vitess horizontal sharding, now what?
If you genuinely shard across many keyspaces with Vitess, that is the one case where a move needs real planning. A single Postgres instance is not a drop-in for a sharded Vitess cluster, so talk to us first. Most apps labelled 'on Vitess' run a single unsharded keyspace and migrate cleanly; true multi-shard workloads need an architecture conversation, and we'll be honest about whether we're the right home yet.
Switch from MySQL to PostgreSQL - with eyes open.
Talk to us before you start. We'll tell you honestly if your app is a one-day migration or a one-week one.