Postgres definitely needs github like tooling that does always online migrations. iirc githhub's migration tool was open source right?
Edit: yes it was https://github.com/github/gh-ost
In EdgeDB is now Gel and Postgres is the futuregithub
gh-ost
Go2016–2025
github / gh-ost
gh-ost
GitHub's Online Schema-migration Tool for MySQL
36Distinct people
42Mentions
1Explicit recommenders
13.6KGitHub stars
What to know before exploring
What it is
GitHub's Online Schema-migration Tool for MySQL
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
We use gh-ost at Harvest[1] and it's a dream in comparison to manually migrating on a replica and switching master/slave roles [2]. Also the linked post[3] in the readme hit us…
zmoazeni used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year42 dated mentions
Observed mentions: 2016-08-02 06:23:47 UTC to 2025-03-01 21:37:46 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 12 | 2 | 10 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
gh-ost
GitHub's online schema migration for MySQL
gh-ost is a triggerless online schema migration solution for MySQL. It is testable and provides pausability, dynamic control/reconfiguration, auditing, and many operational perks.
gh-ost produces a light workload on the master throughout the migration, decoupled from the existing workload on the migrated table.
It has been designed based on years of experience with existing solutions, and changes the paradigm of table migrations.
How?
All existing online-schema-change tools operate in similar manner: they create a ghost table in the likeness of your original table, migrate that table while empty, slowly and incrementally copy data from your original table to the ghost table, meanwhile propagating ongoing changes (any INSERT, DELETE, UPDATE applied to your table) to the ghost table. Finally, at the right time, they replace your original table with the ghost table.
gh-ost uses the same pattern. However it differs from all existing tools by not using triggers. We have recognized the triggers to be the source of many limitations and risks.
Instead, gh-ost uses the binary log stream to capture table changes, and asynchronously applies them onto the ghost table. gh-ost takes upon itself some tasks that other tools leave for the database to perform. As result, gh-ost has greater control over the migration process; can truly suspend it; can truly decouple the migration's write load from the master's workload.
In addition, it offers many operational perks that make it safer, trustworthy and fun to use.
Highlights
Build your trust in gh-ost by testing it on replicas. gh-ost will issue same flow as it would have on the master, to migrate a table on a replica, without actually replacing the original table, leaving the replica with two tables you can then compare and satisfy yourself that the tool operates correctly. This is how we continuously test gh-ost in production.
True pause: when gh-ost throttles, it truly ceases writes on master: no row copies and no ongoing events processing. By throttling, you return your master to its original workload
Dynamic control: you can interactively reconfigure gh-ost, even as migration still runs. You may forcibly initiate throttling.
Auditing: you may query gh-ost for status. gh-ost listens on unix socket or TCP.
Control over cut-over phase: gh-ost can be instructed to postpone what is probably the most critical step: the swap of tables, until such time that you're comfortably available. No need to worry about ETA being outside office hours.
External hooks can couple gh-ost with your particular environment.
Please refer to the docs for more information. No, really, read the docs.
Usage
The cheatsheet has it all. You may be interested in invoking gh-ost in various modes:
a noop migration (merely testing that the migration is valid and good to go)
a real migration, utilizing a replica (the migration runs on the master; gh-ost figures out identities of servers involved. Required mode if your master uses Statement Based Replication)
a real migration, run directly on the master (but gh-ost prefers the former)
a real migration on a replica (master untouched)
a test migration on a replica, the way for you to build trust with gh-ost's operation.
Our tips:
Testing above all, try out --test-on-replica first few times. Better yet, make it continuous. We have multiple replicas where we iterate our entire fleet of production tables, migrating them one by one, checksumming the results, verifying migration is good.
For each master migration, first issue a noop
Then issue the real thing via --execute.
More tips:
Use --exact-rowcount for accurate progress indication
Use --postpone-cut-over-flag-file to gain control over cut-over timing
Get familiar with the interactive commands
Also see:
requirements and limitations
common questions
what if?
the fine print
Community questions
Using gh-ost on AWS RDS
Using gh-ost on Azure Database for MySQL
What's in a name?
Originally this was named gh-osc: GitHub Online Schema Change, in the likes of Facebook online schema change and pt-online-schema-change.
But then a rare genetic mutation happened, and the c transformed into t. And that sent us down the path of trying to figure out a new acronym. gh-ost (pronounce: Ghost), stands for GitHub's Online Schema Transmogrifier/Translator/Transformer/Transfigurator
License
gh-ost is licensed under the MIT license
gh-ost uses 3rd party libraries, each with their own license. These are found here.
Community
gh-ost is released at a stable state, but with mileage to go. We are open to pull requests. Please first discuss your intentions via Issues.
We develop gh-ost at GitHub and for the community. We may have different priorities than others. From time to time we may suggest a contribution that is not on our immediate roadmap but which may appeal to others.
Please see Coding gh-ost for a guide to getting started developing with gh-ost.
Download/binaries/source
gh-ost is now GA and stable.
gh-ost is available in binary format for Linux and Mac OS/X
Download latest release here
gh-ost is a Go project; it is built with Go 1.15 and above. To build on your own, use either:
script/build - this is the same build script used by CI hence the authoritative; artifact is ./bin/gh-ost binary.
build.sh for building the release artifacts (tar.gz archives plus .rpm/.deb packages and a SHA256SUMS manifest) in /tmp/gh-ost-release
Generally speaking, master branch is stable, but only releases are to be used in production.
Authors
gh-ost is designed, authored, reviewed and tested by the database infrastructure team at GitHub:
@jonahberquist
@ggunson
@tomkrouper
@shlomi-noach
@jessbreckenridge
@gtowey
@timvaillancourt
Read the full README on GitHubWhat Hacker News says
42 sourcesIn practice the only option that I’ve seen work for very large teams and very large relational databases is online schema change tools like https://github.com/shayonj/pg-osc and https://github.com/github/gh-ost (the latter developed for GitHub’s monolith). It’s just too difficult to model what migrations will cause problems under load. Using a binlog/shadowtable approach for all migrations mostly obviates the problem.
In My notes on Gitlab's Postgres schema design (2022)"At GitHub we do not use foreign keys, ever, anywhere" (2016)
17 points · Open discussionThis github issue is often linked when this topic is discussed: https://github.com/github/gh-ost/issues/331
> Personally, it took me quite a few years to make up my mind about whether foreign keys are good or evil, and for the past 3 years I'm in the unchanging strong opinion that foreign keys should not be used. Main reasons are:
> * FKs are in your way to shard your database. Your app is accustomed to rely on FK to maintain integrity, instead of doing it on its own. It may even rely on FK to cascade deletes (shudder).
When eventually you want to shard or extract data out, you need to change & test the app to an unknown extent.
> * FKs are a performance impact. The fact they require indexes is likely fine, since those indexes are needed anyhow. But the lookup made for each insert/delete is an overhead.
> * FKs don't work well with online
Read the rest
schema migrations.
Sounds like it's basically explained in the gh-ost readme https://github.com/github/gh-ost#how
I think it amounts to "use views to decouple access to the table with a fixed interface" and "use triggers for migrating data between tables"
In We migrated to SQL. Our biggest learning? Don't use PrismaWith foreign keys, I can't use https://github.com/github/gh-ost for zero downtime migrations. Instant deal breaker, because schema changes are inevitable given business evolution.
In We migrated to SQL. Our biggest learning? Don't use Prisma#. SQLite WAL mode
From https://www.sqlite.org/isolation.html https://news.ycombinator.com/item?id=32247085 :
> [sqlite] WAL mode permits simultaneous readers and writers. It can do this because changes do not overwrite the original database file, but rather go into the separate write-ahead log file. That means that readers can continue to read the old, original, unaltered content from the original database file at the same time that the writer is appending to the write-ahead log
#. superfly/litefs: a FUSE-based file system for replicating SQLite https://github.com/superfly/litefs
#. sqldiff: https://www.sqlite.org/sqldiff.html https://news.ycombinator.com/item?id=31265005
#. dolthub/dolt: https://github.com/dolthub/dolt :
> Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a Git repository. [...]
> D
Read the rest
olt can be set up as a replica of your existing MySQL or MariaDB database using standard MySQL binlog replication. Every write becomes a Dolt commit. This is a great way to get the version control benefits of Dolt and keep an existing MySQL or MariaDB database.
#. github/gh-ost: https://github.com/github/gh-ost :
> Instead, gh-ost uses the binary log stream to capture table changes, and asynchronously applies them onto the ghost table. gh-ost takes upon itself some tasks that other tools leave for the database to perform. As result, gh-ost has greater control over the migration process; can truly suspend it; can truly decouple the migration's write load from the master's workload.
#. vlcn-io/cr-sqlite: https://github.com/vlcn-io/cr-sqlite :
> Convergent, Replicated SQLite. Multi-writer and CRDT support for SQLite
> CR-SQLite is a run-time loadable extension for SQLite and libSQL. It allows merging different SQLite databases together that have taken independent writes.
> In other words, you can write to your SQLite database while offline. I can write to mine while offline. We can then both come online and merge our databases together, without conflict.
> In technical terms: cr-sqlite adds multi-master replication and partition tolerance to SQLite via conflict free replicated data types (CRDTs) and/or causally ordered event logs.
yjs also does CRDTs (Jupyter RTC,)
#. pganalyze/libpg_query: https://github.com/pganalyze/libpg_query :
> C library for accessing the PostgreSQL parser outside of the server environment
#. Ibis + Substrait [ + DuckDB ] https://ibis-project.org/blog/ibis_substrait_to_duckdb/ :
> ibis strives to provide a consistent interface for interacting with a multitude of different analytical execution engines, most of which (but not all) speak some dialect of SQL.
> Today, Ibis accomplishes this with a lot of help from `sqlalchemy` and `sqlglot` to handle differences in dialect, or we interact directly with available Python bindings (for instance with the pandas, datafusion, and polars backends).
> [...] `Substrait` is a new cross-language serialization format for communicating (among other things) query plans. It's still in its early days, but there is already nascent support for Substrait in Apache Arrow, DuckDB, and Velox.
#. ibis-project/ibis-substrait: https://github.com/ibis-project/ibis-substrait
#. tobymao/sqlglot: https://github.com/tobymao/sqlglot :
> SQLGlot is a no-dependency SQL parser, transpiler, optimizer, and engine. It can be used to format SQL or translate between 19 different dialects like DuckDB, Presto, Spark, Snowflake, and BigQuery. It aims to read a wide variety of SQL inputs and output syntactically and semantically correct SQL in the targeted dialects.
> It is a very comprehensive generic SQL parser with a robust test suite. It is also quite performant, while being written purely in Python.
> You can easily customize the parser, analyze queries, traverse expression trees, and programmatically build SQL.
> Syntax errors are highlighted and dialect incompatibilities can warn or raise depending on configurations. However, it should be noted that SQL validation is not SQLGlot’s goal, so some syntax errors may go unnoticed.
#. benbjohnson/postlite: https://github.com/benbjohnson/postlite :
> postlite is a network proxy to allow access to remote SQLite databases over the Postgres wire protocol. This allows GUI tools to be used on remote SQLite databases which can make administration easier.
> The proxy works by translating Postgres frontend wire messages into SQLite transactions and converting results back into Postgres response wire messages. Many Postgres clients also inspect the pg_catalog to determine system information so Postlite mirrors this catalog by using an attached in-memory database with virtual tables. The proxy also performs minor rewriting on these system queries to convert them to usable SQLite syntax.
> Note: This software is in alpha. Please report bugs. Postlite doesn't alter your database unless you issue INSERT, UPDATE, DELETE commands so it's probably safe. If anything, the Postlite process may die but it shouldn't affect your database.
#. > "Hosting SQLite Databases on GitHub Pages" (2021) re: sql.js-httpvfs, DuckDB https://news.ycombinator.com/item?id=28021766
#. >> - bittorrent/sqltorrent https://github.com/bittorrent/sqltorrent
>> Sqltorrent is a custom VFS for sqlite which allows applications to query an sqlite database contained within a torrent. Queries can be processed immediately after the database has been opened, even though the database file is still being downloaded. Pieces of the file which are required to complete a query are prioritized so that queries complete reasonably quickly even if only a small fraction of the whole database has been downloaded.
#. simonw/datasette-lite: https://github.com/simonw/datasette-lite datasette, *-to-sqlite, dogsheep
"Loading SQLite databases" [w/ datasette]
https://github.com/simonw/datasette-lite#loading-sqlite-data...
#. awesome-db-tools: https://github.com/mgramin/awesome-db-tools
Lots of neat SQLite/vtable/pg/replication things
check out gh-ost migrations: https://github.com/github/gh-ost
In Is 20M of rows still a valid soft limit of MySQL table in 2023?Gh-ost is the new hotness. Simple to use and lots of great features: https://github.com/github/gh-ost
In Ask HN: Is PostgreSQL better than MySQL?Use SQL without foreign keys for best performance [0].
[0]: https://github.com/github/gh-ost/issues/331#issuecomment-266...
In NoSQL or SQL – how you make the choice?No, especially on large tables with billions of records. They make online schema changes impossible. More details: https://github.com/github/gh-ost/issues/331#issuecomment-266...
In Ask HN: Do you use foreign keys in relational databases?Actually I never tried but I was scared by the small print of GH not using RDS themselves [1] and Ghost relying on lower-level features that might be not easily available in RDS. Also I had the impression you have to setup a normal non-RDS replica attached to your RDS master?
[1] https://github.com/github/gh-ost/blob/master/doc/rds.md
In Zero downtime migrationsMySQL has some robust tooling in this space. Some of the tools use triggers to copy to a new table. GitHub's gh-ost[1] is probably the state of the art, and uses the binary log stream to replicate the data.
[1] https://github.com/github/gh-ost
In Zero downtime migrationsYou make this claim as if this happens to every company sooner or later, but if a company the size of GitHub can still do without (
https://github.com/github/gh-ost/issues/331#issuecomment-266...) it does become a little bit of a "you do not have google problems" type discussion.
(Perhaps you do have such problems, I don't know where you work! But 99%+ of companies don't have such problems and never will.)
In How we upgraded our 4TB Postgres databaseGitHub doesn't use foreign keys[1], and there's likely many tables related to all the users, notifications, permissions, etc... that would need to be cleaned up. Without foreign keys they likely have some system process that does this instead of a simple `DELETE FROM` which cascades.
1. https://github.com/github/gh-ost/issues/331#issuecomment-266...
In We lost 54k GitHub starsShowing the 15 most recent of 42 sources. Enable JavaScript to search and browse every indexed mention.