Database Migrations: Up Only
A software system without down migrations is a conceptually simpler system, and the lack of (the perception of?) a saftey net makes one think carefully about their approach to database refactors. So long as they don't then avoid the inevitable database refactors, I surmise this can lead to a heathly code practice.
I haven't found a concise intro to this technique, so I made a note on the "refactoring sandwich" technique and included in it an example of using the refactoring sandwich to perform a database refactor.
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 made an up-only database migration tool in Nodejs called Pigmig that will handle database migrations in this style. (Disclaimer: I don't currently have a production service using it.) It is open-source and shows how simple migrations can be when you don't need to support down migrations.
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.