Beyond that however it’s about taking a look at your processes and your particular challenges.
Say if you have a old-school DB with lots of stored procs, no or not enough tests, and that people tremble to update, that DB is a business risk.
You should have backups and contingency plans (eg a hot standby?) to ensure updates are resilient even if something fails. And of course the “good hygiene” of adding columns, using feature flags etc as the other commenter wrote.
Once you’re less worried about the database, you can start refactoring it if you wish.
Refactoring a large, entrenched database is a large topic but re publicly available case studies, have a look at Netflix’s case study on how they migrated their billing system away from Oracle[1].
[1] http://techblog.netflix.com/2016/06/netflix-billing-migratio...