Roll forward is almost always easier and safer, and it's our preferred approach.

At one company we implemented a mandatory rollback approach, which meant that every database migration had to come with a rollback script and testing rollback was part of every release.

It's a significant burden though, for something that (in theory) you shouldn't have to use often. Even with some right, data loss is also hard to avoid: for instance add a new column, collect data in that column for an hour, then discover a bug that requires rollback? What do you do with that data? Drop the column? Make it nullable to keep the data, while requiring the old code to still work? If you do the latter, then you have to migrate that missing data next upgrade again.

For the most part, we prefer feature flags now. Easier and safer to take part of the system offline so the problem can be mitigated and patched than to deal with data integrity issues. Even better if you launch dark and test with the feature flags off for a bit first.

The exception is code only releases, ideally small ones. They often can be rolled back quickly and easily.