Does Vitess DDL revert guarantee data consistency after completion?

Short answer

No. A Vitess REVERT on a completed online DDL migration guarantees schema-level consistency — the table structure returns to its prior definition — but it makes no guarantee about data. Revert is a logical inverse DDL operation, not a point-in-time restore. If you revert an ADD COLUMN, Vitess issues a DROP COLUMN, and every row value written into that column since cutover is permanently destroyed.

What revert actually does

Confirmed behavior of the online DDL lifecycle (Vitess 16+; verify against your version, as artifact-retention defaults have changed across releases):

• Revert applies the inverse statement as a new migration. It does not replay history or restore the pre-migration table contents.
• During an online migration, Vitess copies data into a shadow (artifact) table and swaps at cutover. The original table is kept as an artifact for a limited time.
• Artifact tables are purged by the table garbage collector once their retention window expires. After that, the pre-migration state is unrecoverable from Vitess itself.

Concurrent writes and consistency

If a revert runs after the application has written to new schema elements, those writes are simply dropped with the element. Vitess does not merge, archive, or warn. Consistency is preserved only in the narrow sense that the schema matches the pre-migration definition; the data does not. A revert immediately after cutover, before any writes land in new columns, is the only case where it approximates a true rollback.

Constraining artifact retention for manual recovery

Your real rollback safety net is the artifact table, not revert. To keep that option open:

1. Check the GC retention setting on your tablets: vtctldclient GetTablet <alias> or inspect the --gc-lifecycle / artifact purge interval flags on vttablet. Defaults have shifted between versions, so confirm rather than assume.
2. Do not run DROP on _vt_HOLD_.../_vt_EVAC_... artifact tables manually until the change is validated in production.
3. If you need to roll back after revert is unsafe, rename the artifact table back (a manual, planned operation) rather than relying on revert.

Verifying before you rely on it

On a staging keyspace: run an ADD COLUMN migration, insert rows with values in the new column, then REVERT and confirm the column and its data are gone. Separately, inspect information_schema.tables for _vt_% artifacts after cutover to learn your actual retention window. One missing detail that changes the recommendation: your Vitess version and vttablet GC flags — if you share those, the retention behavior can be pinned down precisely.

Bottom line

Treat revert as a schema convenience, not a recovery mechanism. For genuine rollback capability, control artifact-table retention and take a backup before cutover; assume anything written to new schema elements is forfeit the moment you revert.