The SQLite usage is very tightly integrated with the software. Any urgent rollback is effectively a roll-forward fix of whatever broken software is in production.

When I say urgent rollback I mean rollback within 30 seconds of realizing something went wrong. Do you have this capability?

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...

You 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

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.

Can 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.

I'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.