Online DDL in Vitess 16+: choosing between vitess, gh-ost, and pt-osc strategies for large sharded tables

Context

Vitess Online DDL supports managed, non-blocking schema migrations through several strategies: the built-in vitess (VReplication-based) strategy, plus orchestrated gh-ost and pt-osc. The strategy is selected per migration, for example via @@ddl_strategy or the ApplySchema DDL strategy flag. Documentation for recent major releases (16 and later) describes all three as supported, but does not define an automatic or universally recommended default.

Goal and constraints

The goal is to define a repeatable policy for picking a migration strategy for large, write-heavy sharded tables, where cut-over locking, replication lag, disk overhead, and revertibility all matter. The vitess strategy offers declarative, revertible migrations in supported versions, while gh-ost and pt-osc depend on external tooling behavior that Vitess orchestrates but does not fully control. Behavior also differs across major versions, so any policy must be pinned to the deployed release and verified on staging.

Questions

1. What concrete criteria (table size, write throughput, MySQL version, topology) should drive the choice between the vitess, gh-ost, and pt-osc strategies?
2. How should cut-over impact be measured and bounded under heavy write load, given that "online" cut-over can still briefly stall connections?
3. Is there a supported way to enforce or audit a default strategy cluster-wide so individual migrations cannot silently pick an unsuitable one?