Came here to say the same thing. You can't roll back without rolling back your database, but I've yet to see a good way to accomplish that. What happens to the

Came here to say the same thing. You can't roll back without rolling back your database, but I've yet to see a good way to accomplish that. What happens to the data you collected since your last backup? How much downtime do you need for the db rollback? Also, when you do your rollback, what happens to?: - data in caches like memcached or redis - images on S3/etc whose URLs are stored in the database - session cookies on users' browsers - state you've created on systems you integrate with, e.g. fulfillment, warehouses, email lists, . . . The database is only a portion of your app's "state", and if you suddenly wrench it out of sync with the other systems, you're going to cause problems. If you absolutely need to stop the world while you develop & deploy a fix, then have an "unavailable" message you can quickly drop in for a few minutes. Maybe you'll find a bug that really does require restoring to a backup, but that should be rare and will cause a lot of pain, so making this automated seems very scary. You want to do your restore in a controlled, considered way, so you don't cause even more data mangling than you've already got.