> deploy requests
Deploy requests are pull requests for your schema: branch, change, diff, review, deploy — with Vitess applying the change online, no table locks, no downtime, and a revert window if it goes wrong. This is the workflow that replaces hand-run ALTER TABLE on production. Currently a Vitess (MySQL) feature; Postgres branches apply schema changes directly.
// deploy requests
11 commands$ pscale deploy-request create mydb add-users-table$ pscale deploy-request create mydb add-users-table --into staging$ pscale deploy-request list mydb$ pscale deploy-request show mydb 12$ pscale deploy-request diff mydb 12$ pscale deploy-request review mydb 12 --approve$ pscale deploy-request deploy mydb 12$ pscale deploy-request deploy mydb 12 --instant$ pscale deploy-request create mydb risky-change --disable-auto-apply$ pscale deploy-request revert mydb 12$ pscale deploy-request cancel mydb 12// faq
How is deploying a deploy request different from just running the DDL myself?
Vitess applies the change as an online migration — it builds a shadow copy of the table, backfills it while replicating live writes, then swaps atomically. Millions of rows, zero locks. You also get schema linting, team review, a deployment queue, and a revert that restores the old schema plus data written during the window.
What does --instant do and when should I avoid it?
--instant uses MySQL's ALGORITHM=INSTANT for eligible changes (like adding a column), skipping the shadow-table copy entirely — deployment is near-immediate. The trade-off: an instant deploy cannot be reverted, so reserve it for low-risk additive changes.
How long do I have to revert a deployed change?
The revert window lasts until the deploy request is closed or the retention period passes — data written to the old and new schema is kept in sync during it. Run `pscale deploy-request revert` inside the window for a lossless rollback; `skip-revert` ends the window early once you're confident.