When you run a new version, Duplicati will upgrade the database as you have discovered. We do not currently have any safe way to roll back the version (it would require a test suite that could verify things worked correctly after downgrading).
Instead, Duplicati makes a copy of the database prior to upgrading it. You can then “switch back” by manually renaming the databases, but this will of course not contain anything you did with the new version.
Yes, there were a number of reports of ridiculous slowdowns, but I believe they are fixed now.
I held back creating a new beta build because there were some errors and slowdowns reported, but I believe these are now fixed.
With the recent OneDrive fix, I want to create a new experimental build and then a new beta build (including the multithreading updates).
That means that many people reported problems issuing the repair/recreate commands so it should be fixed. I have an idea for how to fix them but I have not completed the new code. This is the same as in 2.0.3.3 beta, so it does not make sense to postpone the next beta because of it.
(Side note: figuring out why repairs are often needed is also not completed).
I started the release process with 2.0.3.12, hoping to roll out a replacement for the closed OneDrive Live API, but it hit a small roadblock. I will make a new canary from master (hopefully today UTC), and then upgrade to experimental next week.
Edit: made it 2.0.3.13 out!