GitHub engineers built gh-ost specifically to solve the write amplification problem of trigger-based tools. Instead of intercepting writes at the database trigger layer, gh-ost reads the database's own internal change log — the binary log (binlog) — from the outside.
The Tool
gh-ost (GitHub Online Schema Transmogrifier) was open-sourced by GitHub in 2016 after they used it to migrate their own massive MySQL tables. It is now the preferred tool for online MySQL schema migrations at scale.
How Binlog-Based Sync Works
MySQL records every committed write to a sequential log called the binary log (binlog). This log exists primarily for replication — replica servers read it to stay in sync with the primary. gh-ost exploits this same mechanism:
gh-ostconnects to the database and identifies itself as a replica server (a "fake replica").- MySQL streams binlog events to
gh-ostjust as it would to a real replica. gh-ostparses each binlog event. When it sees a write to the original table, it translates it into a corresponding write to the ghost table.- This happens asynchronously — completely outside the user's write transaction.
Throttling: The Key Advantage
Because gh-ost operates asynchronously and outside the database's transaction path, it can throttle itself based on server health metrics. If it detects that replication lag is growing, CPU is spiking, or disk I/O is saturated, it pauses its own backfill work entirely — without affecting user traffic at all. The application continues writing to the original table at full speed; gh-ost simply waits until the server recovers before resuming, using thresholds like a maximum concurrent-thread count and a chunk size that controls how much data moves per backfill iteration.
Pros:
- Zero triggers — no write amplification, no added lock contention.
- Self-throttling based on real-time server health.
- Can be paused, resumed, and even tested in --test-on-replica mode without touching production.
- Supports a "postpone cutover" flag, letting you control exactly when the final swap happens.
Cons:
- Requires binary logging to be enabled (log_bin=ON) and binlog_format=ROW.
- Requires the migration user to have replication privileges.
- Slight lag between original and ghost table means the cutover phase requires a brief write pause.
- More complex operational setup than pt-osc.
A common interview question is: "What's the difference between pt-online-schema-change and gh-ost?" The key distinction is where the sync happens. pt-osc uses triggers (synchronous, inside the transaction, high overhead). gh-ost uses binlog streaming (asynchronous, outside the transaction, self-throttling). Follow up by mentioning that gh-ost requires binlog_format=ROW and replication privileges — showing you understand the operational prerequisites, not just the conceptual difference.