A platform gates schema changes through a reviewable, revertible "deploy request" rather than allowing direct DDL. What does this buy, and what must the mechanism provide?

The problem being solved

In most organisations, schema changes escape the rigour applied to code. They are applied by a migration tool during deploy, or by an engineer with production access, with no review of the effect, no staged rollout, and frequently no rollback path beyond a backup.

They are also the class of change most likely to cause an unrecoverable incident: a lock on a large table, a destructive change applied to the wrong environment, or a schema that the currently-deployed code cannot use.

What a deploy-request mechanism provides

• A reviewable diff of the schema change, treated exactly like a code change — with a reviewer who can see what is being altered before it happens.
• Automatic analysis: is this change additive or destructive, will it lock, how long will it take on a table of this size, does it drop a column that queries still reference.
• Online application, using a shadow-table or binlog-based mechanism so the change does not lock the table and can be throttled and paused.
• A postponed cutover, so the long copy completes and the brief swap happens at a moment a human chooses — separating the long risky part from the short risky part, which is the main operational benefit.
• Revert as a first-class operation. The original structure is retained for a period, so undoing the change is an operation rather than a restore. This is the property that changes the risk profile most.
• A record of who changed what and when, which is both an audit requirement and an incident-investigation asset.

What must still be enforced outside the mechanism

The tooling makes the change safe; it does not make the change correct. The application-side discipline remains essential:

Schema changes must be backwards compatible with the currently-deployed code, always — the expand-contract sequence: add nullable → deploy code writing both → backfill → deploy code reading new → remove old in a later release.

Each step is independently deployable and revertible, and the failure is combining them. Shipping a schema change with the code that requires it means rolling back the code leaves a schema it cannot use, and rolling back the schema destroys data the new version wrote. The team is trapped between two bad options during an incident, which is exactly when the trap is discovered.

Why the gate is worth the friction

Direct DDL access to production is the equivalent of pushing to the main branch without review, and it persists because schema changes feel like operations rather than changes.

The mechanism converts them into changes — reviewable, testable, staged, revertible — at the cost of a slower path for a category of work engineers are used to doing immediately. That friction is the point, and the answer to the resulting complaint is to make the gated path fast rather than to reopen the ungated one.