GitHub's Online Schema-migration Tool for MySQL
13.5k
Stars
1.4k
Forks
332
Open issues
30
Contributors
AI Analysis
gh-ost is GitHub's triggerless online schema migration tool for MySQL, enabling zero-downtime table alterations on large production databases. It is purpose-built for database administrators and DevOps engineers managing MySQL infrastructure at scale, particularly those operating on large tables where traditional migration tools introduce excessive lock contention. It is not suitable for teams using PostgreSQL, SQLite, or other non-MySQL databases, nor for small development databases where do...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
GitHub's triggerless MySQL online schema migration tool, built for production safety at scale
gh-ost solves one of the most operationally risky problems in MySQL production environments: altering table schemas on live, high-traffic databases without downtime or excessive load. By replacing trigger-based approaches with binary log streaming, it gives operators true pause control, dynamic reconfiguration, and safe cut-over timing. Built by and for teams running MySQL at serious scale — primarily database engineers and site reliability engineers at companies where schema migrations on large tables are a regular operational challenge.
Released by GitHub in 2016 as a replacement for trigger-based tools like pt-online-schema-change and Facebook's OSC. It emerged from years of operational pain at GitHub's own MySQL infrastructure and was open-sourced as a complete, production-hardened solution rather than an experiment.
Growth was driven primarily by word-of-mouth among the MySQL DBA and SRE community. The tool filled a well-known gap — trigger-based migrations were widely understood to be risky on busy tables. GitHub's credibility as the author, combined with thorough documentation and testable-on-replica design, gave adopters confidence. Growth has been steady rather than explosive, reflecting a specialized but real audience.
gh-ost was developed and is used by GitHub on their own production MySQL infrastructure, which constitutes a high-credibility production reference. The README references fleet-wide migration testing across production replicas. Download badge and 13,400+ stars from a technically demanding audience further support real-world adoption at scale. Multiple cloud-specific documentation pages (AWS RDS, Azure) indicate adoption beyond on-premises deployments. Adoption at other organizations is not directly documented in README but is widely reported in the MySQL DBA community.
Appears to use MySQL binary log streaming (via replication protocol) to capture row-level changes asynchronously, applying them to a ghost table alongside incremental row copying. Likely connects to a replica to read binlogs, reducing load on the master. A Unix socket/TCP interface enables runtime interaction and auditing. Based on README, control flow includes distinct phases: copy, throttle, cut-over — each independently pausable.
README references continuous replica-based testing in production ('This is how we continuously test gh-ost in production') and mentions a dedicated CI workflow for replica tests (replica-tests.yml), suggesting meaningful integration test coverage. Unit test coverage not documented in README.
Last push was 2026-06-26, two days before the evaluation date — the project is actively maintained. It has been maintained for 10 years, indicating long-term commitment from GitHub. CI badges are present and passing per README. The combination of longevity and recent activity suggests healthy ongoing stewardship rather than legacy drift.
ADOPT IF: you run MySQL at meaningful scale where schema migrations on large tables pose real risk, need true pause capability during high-traffic windows, or have been burned by trigger-based tools before. AVOID IF: you are using PostgreSQL (gh-ost is MySQL-only), your tables are small enough that native ALTER or simpler tools carry no meaningful risk, or your MySQL setup lacks binary log access (e.g., some managed cloud configurations). MONITOR IF: you are evaluating whether MySQL 8's improving native DDL capabilities reduce your need for external tooling, or if your organization is migrating toward Vitess which absorbs gh-ost functionality internally.
Independent dimensions
Mainstream potential
4/10
Technical importance
9/10
Adoption evidence
8/10
- MySQL-only scope permanently limits the addressable audience; teams on PostgreSQL or mixed database environments must maintain separate tooling.
- Binary log streaming adds operational complexity and requires BINLOG access, which may be restricted or unavailable in some managed database environments despite documented RDS/Azure workarounds.
- Dependency on GitHub as primary maintainer — if GitHub migrates away from MySQL or deprioritizes the tool, community capacity to sustain it long-term is uncertain, though the 10-year track record reduces this concern.
- Native MySQL improvements (Instant DDL in 8.0+) may gradually reduce the urgency of the problem gh-ost solves, potentially narrowing its use cases over time.
- Cut-over phase still requires a brief lock window; users needing truly zero-lock migrations may find edge cases where this is unacceptable.
gh-ost will likely remain the de facto standard for high-stakes MySQL schema migrations for the foreseeable future. MySQL's continued dominance in web infrastructure and the tool's strong operational track record suggest stable, if not growing, adoption.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Go
- License
- MIT
- Last updated
- 2w ago
- Created
- 125mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Top contributors
Similar repos
rubenv/sql-migrate
SQL schema migration tool for Go applications that supports multiple databases...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
github/gh-ost
this
|
13.5k | +9 | Go | 8/10 | 2w ago |
 pressly/goose
|
11k | — | Go | 8/10 | 6d ago |
 go-mysql-org/go-mysql
|
5k | — | Go | 8/10 | 22h ago |
 xataio/pgroll
|
6.5k | — | Go | 8/10 | 3w ago |
|
rubenv/sql-migrate
|
3.4k | — | Go | 7/10 | 1mo ago |
 golang-migrate/migrate
|
18.7k | — | Go | 8/10 | 5d ago |
The most direct predecessor and competitor. Uses triggers internally, which gh-ost explicitly avoids. Trigger-based approach creates write amplification and prevents true pause. pt-osc has broader MySQL version compatibility and is more familiar to legacy DBAs, but gh-ost is generally preferred for high-traffic tables where trigger overhead matters.
Another trigger-based ancestor. Less actively maintained as a standalone open-source tool. gh-ost's binary log approach directly addresses limitations identified with tools like fb-osc.
Vitess includes its own online DDL mechanism and can use gh-ost internally as a migration strategy. For teams already on Vitess, the integration is available. For those not on Vitess, gh-ost is a lighter-weight standalone option without the full Vitess operational overhead.
Fundamentally different tool — manages schema migration versioning and sequencing rather than safe live execution. The two tools address different layers of the problem and are often used together rather than as alternatives.
MySQL 8 has improved native online DDL support, and some operations can now be done instantly. However, native DDL still lacks the operational controls gh-ost provides (pause, dynamic throttle, safe cut-over timing), and not all ALTER operations qualify for instant execution. gh-ost remains useful even on MySQL 8.
