There are other ways to approach the same problem even with a single instance, without risking the downtime.
- Instead of renaming a column, you create a new one with the new name.
- Allow your new code to read from the old field if the new isn’t populated.
This ensures that in the event of a rollback on your deploy both the old and new code will work with the new state of your database. This is critical for a zero-downtime deployment.
If the deploy is successful:
- Kick off a background job to populate the new field after a successful deployment.
- On next deploy, remove the old field.
If you’ve got an application with a steady amount of traffic, that is the only safe way to avoid downtime. Two databases doesn’t actually do you any good because no matter what the old and new state of your application code have to work with the new state of the database. If you want to do that at the database level with a view that’s fine too…as long as the precaution is taken. The instant you rename a column, the old state of your application code no longer functions.
If you have two databases you can change it on one…but as soon as you make that change they are no longer in sync. As soon as their states no longer line up, you’re going to run into the exact same issue if new data is getting written to the different name.
You can do it, you just have to do it more steps than just using “rename”. In the early days of a project it’s not a big deal. When a project gets larger and people begin to rely on it, it’s reckless without proper precautions.
