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.

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.

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.

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.

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.

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.

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.

Every applied migration is logged with version, environment, executor, and timestamp. Each entry keeps a schema snapshot, and schema sync compares any two databases and realigns them through the same pipeline.

MySQL 9.7's MASKING POLICY object enforces server-side — but only on Enterprise Edition and OCI HeatWave. Community, Percona, and every managed flavor are out.

Functions like mask_ssn() bound through views. One view per role × variation, and every schema change ripples through the set. Enterprise-licensed, or Percona Server only.

Masking runs in the proxy, not the server — a BSL-licensed connection layer to deploy and lock down. Anyone reaching the port behind it reads cleartext.

MySQL Community ships nothing. RDS, Aurora, and managed forks ship none of the above. The most common production MySQL has no native masking at all.

Workspace rules, first match wins. Conditions on environment, project, database, and classification pick the algorithm — full, partial, MD5, range, custom. One rule covers the Enterprise cluster, the Percona shard, and the Community staging instance.

Project-level override for a single column.

Time-bound Query or Export exemptions for named users. Every grant logged. Every access logged.

Nobody writes a column-scoped GRANT for 'agent'@'%' before a five-minute setup. They paste the DSN they already have — and a MySQL GRANT is table- or schema-wide, so that login reads and drops far more than the one table the agent needed.

MySQL Community ships no audit plugin — Enterprise Audit, Percona's audit_log, and MariaDB's server_audit are each edition- or fork-specific. The one built-in everywhere, the general query log, is a debug firehose that records 'agent'@'%' and nothing about which agent, which user, or which prompt.

Two MySQL facts break the usual guard. A connection with multi-statements enabled runs SELECT 1; DROP TABLE orders in a single round trip, and MySQL DDL implicitly commits — a DROP or TRUNCATE can't be rolled back, so wrapping the agent in a read-only transaction sandboxes nothing.

The agent reads data, ingests untrusted content, and sends it back out — the lethal trifecta in one shot. A scoped credential can't stop an injection that asks for data it's allowed to read.

The agent authenticates as itself, not as a DSN. Scope follows the identity — only the projects, databases, and tables its role allows.

Sensitive values are masked before they reach the model. A restricted SSN comes back as ******, so it can't leak what it never saw.

A change doesn't run on send. It opens a Bytebase issue, where SQL review and approval apply just as for a human-authored migration.

Database governance for MySQL.

Schema Migration

Data Masking

MCP Server

Connect MySQL

Explore the standard for database governance

Solutions & Platform

Resources

Change Management

Access & Security

AI & Agents

Comparisons

Company

Legal