Online Schema Migration
Run large MySQL schema changes without downtime
What happens when a large MySQL ALTER hits production
The ALTER locks the table for a rebuild
On a large InnoDB table, an ALTER the engine can't do in place rebuilds the whole table and holds a metadata lock. Writers stall for the length of the rebuild — discovered only in production.
MySQL downgrades to COPY silently
For operations INSTANT and INPLACE can't handle, MySQL falls back to a locking COPY without telling you. A change you tested on an empty table behaves nothing like it does on a billion rows.
gh-ost is one more system to run
The standard answer — gh-ost or pt-online-schema-change — means a separate tool to configure, throttle, and babysit, wired up by hand for every change.
How Bytebase runs MySQL migrations online
Online DDL or gh-ost, chosen by the change
Bytebase looks at the table size and the operation, then runs the migration the cheapest safe way — native Online DDL when the engine can do it in place, gh-ost when it can't.
Online DDL when it's safe
For changes MySQL can do in place — INSTANT or INPLACE — Bytebase runs them natively, with no shadow table to manage.
gh-ost when COPY is too costly
When MySQL would fall back to a locking COPY, Bytebase routes the change through gh-ost: a shadow table built from the binlog, then an atomic cut-over.
Replica-aware throttling
gh-ost throttles on replica lag, so a billion-row migration doesn't stall the followers sitting behind production.
Reviewed and sequenced before it runs
Every migration clears SQL review and rolls out across environments in order, so a locking statement is caught before it ever reaches production.
Lock-aware SQL review
100+ rules flag locking DDL, missing algorithm hints, and backward-incompatible operations before the migration merges.
Sequenced rollout
Changes deploy dev → staging → production in order, so the same migration is proven on lower environments before it touches prod.
Built-in rollback
Every change carries its diff and a generated rollback plan, so reverting a migration is a click, not a manual rebuild.
Governed end to end, not a script someone runs
The gh-ost run sits inside the same change workflow as everything else — approvals, audit, and access control — instead of a tool operated by hand on a production box.
Risk-tiered approval
Large or destructive migrations route to a human; safe, bounded changes deploy automatically.
No direct production access
Run a production migration without ever holding a production credential — Bytebase brokers and records every change.
Full change history and audit
Every migration is logged with author, diff, algorithm, and timestamp — an audit trail you don't assemble by hand.
One MySQL migration workflow, controls for every team
Designed to integrate across modern enterprise environments
Bytebase connects to databases, developer tooling, and collaboration platforms to fit naturally into complex, multi-tool enterprise ecosystems.