Hacker News Reader

One caveat regarding "Always put each migration into a database transaction": I've found that for very large database tables on a live system, it becomes impractical to e.g. create a new index inside a transaction, because the entire table would need to be locked for the duration of the operation.

View on HN

That's because this entire approach is broken: if one cannot afford to bring database down to do alter table migration, one should always go a lazy migration either via application stack using write-to-new only, read from new on miss, read from old, followed by a backfill or using triggers.

Is this not what PostgreSQL's MVCC was created to help mitigate?

https://www.postgresql.org/docs/current/static/mvcc-intro.ht...

Reply on news.ycombinator.com