Two databases is a good idea but there a few read-only-but-not-really tables that muddy up the waters on the idea of multiple db's. Pretty relevant tables too, such as TechSystem: (this may also be a reason against it happening on C# by the way)
Any new research project you create gets added here but this also contains vanilla stuff like fuel tanks.
I strongly advise not to write a script that migrates an existing game into a new db. That's a lot of work and would be incredibly easy to mess up and would cause all kinds of very-very-nasty bugs. I also don't recommend providing a drop-in db, because the database gets updated fairly regularly as I add more helper columns and tables. Instead, put a database modification script in your on_program_load file. It would be pretty simple. Say you wanted to remove the Trans-Newtonian Tech requirement on Flag Bridge. You could have the following in your on_program_load function:
update TechSystem set Prerequisite2 = 0 where TechSystemID = 225 and Prerequisite2 = 27434The
"Prerequisite2 = 27434" section nicely skips the update if some other mod has already messed with that field or a future database version has fiddled with it. Doing it this way ensures that your mod is still active even after future database updates. If, for arguments sake, the entire Prerequisite2 column got deleted (it wont) making your mod no longer compatible, then the SQL would harmlessly fail. Bad SQL fails silently, it doesn't crash.
You would just have to give the user a caveat that your mod is permanent and if they want to revert the change they'll have to redownload the database file. (Which is the same amount of work that would be required for the database-dropin approach anyway.)