2 ms·

Sure, but 99% of the databases are small enough to have some degration/downtime/exceptions. If something goes wrong, just roll back. There's no difference in t

Sure, but 99% of the databases are small enough to have some degration/downtime/exceptions. If something goes wrong, just roll back. There's no difference in that. "Zero downtime migrations" like only cover adding columns. Let's say you change a relation from n-1 to a n-m.. this is not gonna save you. You need to deploy a new version of the code. If you want to roll back, you might loose data, or some code doesn't work. It's just a mess, takes more time, is more error prone. Most companies are not "big tech".

KiranRao0 5y ago
Author here, and a few things I'd like to clear up. > 99% of the databases are small enough to have some degration/downtime/exceptions I agree that most DBs are small enough to perform the migration operation in a single transaction. However the choice to have downtime isn't solely an engineering question. It's also a product/business consideration. > Let's say you change a relation from n-1 to a n-m.. this is not gonna save you. You need to deploy a new version of the code. If you want to roll back, you might loose data, or some code doesn't work. It's just a mess, takes more time, is more error prone. Agreed. This article isn't meant to cover every possible migration, but a good starting point for most of them. Gives a framework to make think about how to implement n:1 -> n:m > Most companies are not "big tech". I'm not working in big tech. I'd consider myself working firmly within small tech. And these technique exactly the same if we had exactly 1 API server and 1 small database instance.