An ALTER TABLE that takes 3 ms can still stall every query on the table. In my first demo it took 3 ms. In a second one, on real Postgres, a long transaction held the table, so a similar ALTER waited about 3 seconds, and a plain SELECT that arrived after it waited 2.7 seconds, though it only needed to read. That queue is how a "metadata-only" migration becomes downtime. Here is the method for a 5-billion-row table, with two scripts you can run.

I asked this on X, translated from Portuguese: "How would you do a migration on a 5-billion-row table with no downtime?" It reached 23K views and 33 of the replies had text. 3 gave a method, 9 talked about using an AI for it, and 6 said the hard part is knowing what to ask first: which database, how critical, what the tables look like. The replies are paraphrased and no one is named. This is the answer I would give.

The queue is the downtime

Two scripts, both run on my machine. The first uses PGlite, Postgres compiled to WebAssembly, in memory, with 1 million rows.…