# MySQL Schema Migration — Database CI/CD for MySQL > MySQL has no transactional DDL — a multi-statement migration that fails leaves the table half-applied, with no rollback. Bytebase puts MySQL change on a CI/CD pipeline: reviewed, run online through gh-ost when an ALTER would lock, staged, approved, and audited across Community, Percona, MariaDB, RDS, and Aurora. Source: https://www.bytebase.com/databases/mysql/schema-migration/ --- ## Your app ships through CI/CD. Your MySQL schema ships from the mysql CLI. A developer runs ALTER TABLE straight at production — no review, no staging, no record. And MySQL has no transactional DDL: fail on the third statement and the first two are already live, with nothing to roll back. Bytebase puts MySQL change on the same pipeline as your code — reviewed, run online when an ALTER would lock, staged, approved, and audited — from a Git pull request or the Bytebase UI. On MySQL the ungoverned path carries risks the engine won't catch for you: ### No transactional DDL A migration is a sequence of statements, and MySQL commits each ALTER as it runs. The third one fails and the first two are already live — nothing to roll back, no clean retry. You reconcile by hand, in production. ### ALTER locks the table A plain ALTER on a large InnoDB table can rebuild it whole, holding a metadata lock that stalls reads and writes. That's why teams reach for gh-ost or pt-online-schema-change — then have to wire that into the pipeline too. ### Replicas fall behind A long ALTER serializes through the binlog on every replica, so a 20-minute rebuild on the primary becomes 20 minutes of replication lag and stale reads downstream. A change that looked fine on one server degrades the whole topology. ### Every edition behaves differently Online DDL on 8.0 isn't online DDL on 5.7, MariaDB, or Aurora — an ALTER that's instant on one is a full table copy on another. The safe path depends on where the change lands. ## Every change runs the same path. A change starts as a Git pull request or in the Bytebase UI — and from there the path is one, the same across Community, Percona, MariaDB, RDS, and Aurora. The migration script is the same in every environment. What changes is the gate in front of each. ### Validate SQL review runs on the change before it applies — 200+ rules catch table-locking ALTERs, a missing primary key, utf8mb3 columns, and naming violations. The ruleset is strict on production, relaxed on dev. ### Promote The migration applies in dev, then staging, then production — and across a whole database group in one rollout, not a mysql loop over every schema. The same script meets progressively more realistic data, run online through gh-ost when an ALTER would otherwise lock or lag the replicas. A failure stops the chain before production. ### Approve Approval gates sit between stages. Routine changes auto-promote into dev; production-bound DDL waits for a human who sees the SQL, the review results, and the rollout plan in one record. ### Record Every applied migration is logged with version, environment, executor, and timestamp. Schemas are compared automatically, and a change made outside the pipeline triggers a drift alert. ## The half-applied migration, caught before it runs. A developer reshapes an 18M-row table in four statements. SQL review reads it before anything runs: ``` -- V042__split_users_name.sql ALTER TABLE users ADD COLUMN first_name VARCHAR(255) NULL; ALTER TABLE users ADD COLUMN last_name VARCHAR(255) NULL; UPDATE users SET first_name = ..., last_name = ...; ALTER TABLE users DROP COLUMN full_name; -- ⚠ SQL review (production ruleset) -- • each ALTER auto-commits — no transaction wraps these four steps -- • a failure after step 2 leaves the table half-migrated, no rollback -- • ALTER on 18M rows: route through gh-ost to keep it online ``` The same script promotes through dev and staging before a human approves it for production. Each environment keeps its own audit trail. ## Planned schema change — and it says so. The pipeline gates one class of work, and gates it well: planned schema change. Emergency hotfixes, one-off data patches, and an OPTIMIZE TABLE during an incident don't arrive as a reviewed change — and forcing them through the pipeline only teaches people to route around it. ## Common questions. ### Does MySQL have built-in schema migration or versioning? No database does, really — versioning is a tool's job, not a database's. MySQL runs whatever SQL it receives without recording which migrations ran, enforcing an order, or reviewing a change first. The process around it comes from a migration tool like Flyway or Liquibase, or a pipeline platform like Bytebase that adds review, promotion, and audit on top. ### What happens if a multi-statement migration fails halfway? MySQL commits each DDL statement as it runs and can't wrap them in a transaction, so the statements that already executed stay applied — you're left half-migrated with no rollback. That's the core reason to put MySQL change on a pipeline: review catches the hazard before merge, and staged rollout means a half-applied migration surfaces in dev or staging, never first in production. To undo a change that's already live, the down migration runs as its own reviewed, audited change. ### Does it handle online schema change on large tables? Yes. For a large-table ALTER that would otherwise lock or copy, Bytebase runs the migration through gh-ost — applying the change to a ghost table and swapping it in with minimal locking. SQL review flags the lock-heavy operation first, so the online path is chosen before merge, not discovered during the incident. ### Will a big ALTER lag my replicas? It can. A long ALTER serializes through the binlog on every replica, turning a slow rebuild on the primary into replication lag and stale reads across the topology. Staged rollout shows the impact in staging before production, and gh-ost throttles on measured replica lag so the change doesn't outrun the replicas. ### Which MySQL flavors are supported? Any MySQL or MariaDB Bytebase can connect to — Community, Enterprise, Percona, MariaDB, RDS, Aurora, Cloud SQL, managed forks. The pipeline runs in front of the database, so there's no plugin or component requirement on the server. ## Get Started - [Contact us](https://www.bytebase.com/contact-us/) - [Start now (cloud)](https://console.bytebase.com)