A software system without down migrations is a conceptually simpler system, and the lack of (the perception of) a safety net makes one think carefully about their approach to database refactors. I believe this is a healthy code practice.
What the down migration provided was a kind of safety net in case a particular migration went wrong. Practically these are not always well tested, but conceptually they were still a safety net.
In a roll-forward strategy you can still have this safety net. It is in the small-step-by-small-step evolution of the database and source code. Each small step does one or two small things that are easy to test while also being backwards compatible with the previous step. This simplifies change sets while preserving test suites.
Strategies
Transition periods
https://documentation.red-gate.com/fd/rollback-guidance-138347143.html
One strategy is to implement the database refactor and have it co-exist alongside the old database model. There would then be code-level changes to accommodate the data-level changes during some transition period. This could be feature flags or changes to read and write calls, etc. It introduces more control over the change when compared to a hard switch hope-for-best release.
Aqua Database
https://michaeljswart.com/2018/01/100-percent-online-deployments-blue-green-deployment/
This is a take on blue-green deployment which is technique to have zero downtime servers by using a load balancer to switch between your current blue servers and your new green servers. Database are not as amenable to this kind of technique because it could lead to data corruption or odd read/write preventions. One solution to this is to extend the steps in the blue-green deploy. First add unconnected green server, second run migrations scripts that make your blue db aqua (you've added the green), third swap to the green servers which are also pointing to your now aqua db, fourth run migration scripts to make your aqua db green (you've removed the blue).
Example: Column Name Change
Imagine you want to rename a column. The steps would approximately be as follows. Assume c1 is the original column for some table, and c2 is the renamed column.
- source code reads and writes to c1
- db migration adds c2 (source code doesn't know about it) by copying all values over from c1 (or making the all null if performance is a problem and running the copy later)
- source code deploy still only reads from c1 but now writes to both c1 and c2
- db migration drops non-null constraint from c1
- source code deploy enables reads and writes exclusively from c2
- db migration drops c1
Names for this include Aqua Databases, which is a nod to blue-green deploys, split column migrations, expand-contract migrations, etc.
No rollbacks in the wild
StackOverflow cannot rollback
Spiritually, they can rollback because if they made a mistake in a database migration, they can push a new migration to fix it, a "roll forward". Here is a quote from Nick Craver on how StackOverflow deployed code
The tooling has no concept of rollback though. Why roll back when you can roll forward?
Earlier on in the same paragraph, he mentions how he can't remember ever doing a rollback at StackOverflow (given his claim that the tooling doesn't support it to begin with, I assume this means they haven't every rolled back "conceptually speaking", aka, done a roll-forward. In my experience of years of professional software development, I also have no memory of every performing a rollback. It makes sense to fear a bad migration, since data is the unshakeable truth of all software. But, also, in every other situation, code that never gets used gets deleted, and code that never will be used should never have been written.
I'm not going out of my way to build systems that have up-only migration strategies, nor am I suggesting you do so. But, speaking for myself, if I'm in a situation where the migration strategy is yet to be determined, I think I will advocate for an up-only migration strategy.
Flyway recommends rolling forward
This is their article on rollback guidance. At the bottom of it are links to additional resources, relinked here:
Spring recommends not doing database rollbacks
https://spring.io/blog/2016/05/31/zero-downtime-deployment-with-a-database#assumptions
Their recommendations are to be capable of application rollback for at least one version, and to have no database rollbacks.