In order to update a MySQL database, Cumulus would have to be linked with a MySQL client library,
Which, regarding to this discourse, is fairly unimportant. I think MySql came into this thread because I suggested it , but I have since learnt that SqLite is a much better and more user-friendly idea to bundle than MySql.
But if you would not distribute said client library, you'd be ok offering MySql as a non-default option. If you would want to choose SqLite as the default, but would want to offer other DB engines as an alternative, and I would choose MySql, I would have to install the client myself. I would then have the dbProvider section in my machine.config, which negates the need for you to put it in your app.config. The only thing you'd have to come up with in your app.config is a valid connection string.
Now, of course, when there would be a difference in SQL syntax between the database engines (Obstacle comes to mind, but something simple like data type stuff can also upset us), the plot, she would thicken. Enter Entity Framework, which abstracts the database layer... and even when the storage model (and thereby also the mapping model) would change because some database engine only wants field names in uppercase, or insists on using NCLOB instead of NVARCHAR, we could generate storage models and mappings at design-time, rather than run time which is the default behaviour of EF...
For me, it would be ideal if the software would offer the option of using SqLite, or use a SQL or MySql database engine that I already have. But if Steve decides to keep it as it is, I'm not going to complain profusely.