2 ms·
Shouldn't you do DB updates in production in a way that N backend always works at least with N+1 schema? So you just rollback the backend...
by megous 5y ago
Shouldn't you do DB updates in production in a way that N backend always works at least with N+1 schema? So you just rollback the backend...
- redis_mlc 5y agoThis is the correct answer in almost all cases for managing production databases. However, developers who use postgres never got the memo, and are trying to do mass rollback transactions of schema changes "cause it worked on my dev notebook." Source: DBA who manages tables with billions of rows.
- developuh 5y agoCan you please explain this like I'm 5. I am still learning and I would like to understand how to do upgrades in a better way.
- Gadiguibou 5y agoI'm not the original commenter, nor am I experienced with upgrading in general, but what I understand from the comment is that you always make sure that your current schema is compatible with the previous backend. For example, this could mean that you don't delete any column that were still in use in the previous backend version. This would have the advantage of letting you rollback your backend alone if anything wrong happens.
- DenisM 5y agoYou could do it that way, but I don't have the need, so my way leads to faster dev cycle: https://news.ycombinator.com/item?id=29566574 https://news.ycombinator.com/item?id=29566574 Doing as you say requires two deployment for each change with a pause in between, and likely two separate merges (does it?). This reduces the deployment velocity. I might have to do as you describe when I start scaling out - there is no hope of updating many servers in sync so might as well embrace multi-version.