PlanetScale

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Do not build this. Schema changes without downtime is the product, and it rests on a sharding layer that took years.

Applying a migration to a large table without locking it, with a branch you can develop against and a request to merge the schema, is real engineering. At small scale you do not need it; at large scale you cannot build it.

WHEN TO KEEP PAYING
- Tables large enough that an ordinary migration locks them for minutes
- A team where schema changes need review before they reach production

WHEN NOT TO
- A table of a few million rows on a modern database, where migrations complete in seconds
- Small enough that SQLite on the application's own machine is the honest answer

WHAT REPLACES EACH FEATURE
- **Schema branching** becomes a copy of the database restored into a preview environment, anonymised on the way, with the anonymiser part of the branch script rather than something somebody remembers
- **Non-blocking migrations** become discipline: **backwards-compatible in both directions across a deploy.** Add a column, deploy, write to it, backfill in batches, then read from it, and only remove the old one in a later deploy. Never two of those steps in one release. That rule removes most of the need for special tooling, and it costs nothing
- Backfills in batches with a sleep between them, so a migration never holds a long transaction
- An index added concurrently where the engine supports it, and never inside a deploy's critical path
- **Point-in-time restore** becomes continuous archiving of the write-ahead log to object storage, which gives a recovery point measured in seconds

AND THE PART NOBODY DOES
- Test every migration against a restored copy of production before it goes near production. That single habit catches more than any platform feature
- Rehearse a restore onto a clean machine and write down how long it took. That number is your actual recovery time, and almost nobody knows theirs

THE ONE-LINE VERSION
Buy it for tables too large to migrate normally. Otherwise adopt the two-deploy migration rule, which is free and solves the same problem.