We discussed again our journey to a single RDBM in another thread and I want to pull it to the top:
The ultimate goal is to have only a single RDBM for both development and production. This will simplify code, support and allow us to leverage specific feature of the picked system which is PostgreSQL. The proposal and schedule is:
- announce on our blog that 1.23 will be the last release supporting MySQL
- implement a warning UI bar that MySQL is ending soon
- release 1.23 with tested documentation on how to migrate to MySQL
- drop MySQL from CI
- drop MySQL from docker image
- remove all MySQL custom queries from the codebase
- remove MySQL from the installer
- release 1.24 with tested documentation on how to upgrade
- solve technical challenge of generating apipie bindings without SQLite
- drop SQLite
- remove all custom code SQLite
- start working on integrating modern PostgreSQL features, for example
- macaddr, macaddr6, ip, ip6
- full text search
- hash indexes
- stored procedures (for very specific updates - e.g. fact or report import)
- push a warning bar in a 1.22.x update to inform users even more early
I am willing to be owner of this effort if we agree with the plan.
Now, this is possibly disturbing change for our users. Unfortunately we don’t have data on how many users have MySQL, I looked in Community Surveys 2016-2019 and we haven’t asked. So no idea how many users will be affected.
The goal for the initial phase is to gather feedback from the field. In the worst case, we end up with instructions how to migrate database (we already have something in our docs) and we can cease or postpone actual removal if it turns out too many users are affected.