Not exactly. This whole topic is sort of in violation of the it-hasn’t really-been-tested caveat, but at least the click-source-tree plan (don’t even need to sign into anything) can tell you when DB version WILL complain. As a side note, I can’t recall any downgrades that didn’t work due to something other than the DB versions.
Based on what I wrote (assuming I wrote/re-read it right), latest experimental and latest canary should play fine on DB version. Presumably move forward to next beta would also work. Downgrade to 2.0.4.5 will not.
At the moment, latest
Canary is v2.0.4.22-2.0.4.22_canary_2019-06-30
Experimental v2.0.4.21-2.0.4.21_experimental_2019-06-28, and IIRC the actual code is basically rebuild of v2.0.4.20-2.0.4.20_canary_2019-06-25 (sometimes an Experimental is custom-blended, but this was not).
Because downgrade from latest canary to latest experimental is only a small step, possibly your reason is getting off the Canary upgrade treadmill (which by design is bleeding-edge). If so, you can instead change channel to Experimental in Settings, overriding the default of Canary channel you have if you install Canary.
Getting information about your setup (specifically System info tab) might help before you change things, especially since you gave a thought in some topic that you got an update in violation of the channel plan. Info from these two screens I mention (Settings, and System info) might give a clue on what happened.
I don’t know the code that well, but I believe the check is at open time. The server DB opens right away to even show you your backup jobs screen. Some specific backup DB is probably not opened until required. There is a backup taken (as mentioned earlier), and one change in recent versions is now the backup file name includes the name of the file it came from (as opposed to just a date, leaving one a difficult guess).
Differens in database files, what are they?
Include original database filename when saving database backup. #3792
So while I’m not making a firm promise, Duplicati doesn’t AFAIK handle multiple DB versions at once. Its solution is to upgrade (as required) on first use (unless it does everything in sight – look at your results).
So I seriously doubt a late DB version complaint is possible.
What’s definitely possible is that the backup of the old DB taken at version update time will grow obsolete rapidly as new backups occur. Trying to revert to it as part of a downgrade will mean losing new versions. Possibly this is what you were getting at. There’s a small time window on a given backup to go back, and possibly testing a less critical backup first when you do a major version jump would be the safer method.