MediaWiki users overwhelmingly choose MySQL/MariaDB:
Pingback:
mysql:research@analytics-store.eqiad.wmnet [log]> select count(*) as num, event_database from MediaWikiPingback_15781718 group by event_database order by num desc; | 8566 | mysql | | 265 | sqlite | | 149 | postgres | | 3 | mssql |
WikiApiary: mysql: 21214, postgres: 283, sqlite: 144, oracle: 3, mssql: 1
PostgreSQL and SQLite usage is 1-2% and Oracle/MSSQL is zero within margin of error.
So there is little reason to spend much effort on supporting alternative backends. And de facto they are not supported. CI tests only run for MySQL, almost all developers only test on MySQL, and most DB-using extensions don't go out of their way to support others either. The policy says DB patches must support all five backends but that's fiction:
~/Wikimedia/grep/extensions$ find . -name '*.sql' | cut -d/ -f2 | uniq | wc -l 161 ~/Wikimedia/grep/extensions$ for db in postgres sqlite oracle mssql; do echo -n "$db: "; find . -name '*.sql' | ack $db | cut -d/ -f2 | uniq | wc -l; done postgres: 14 sqlite: 11 oracle: 4 mssql: 3 ~/Wikimedia/grep/extensions$ find . -name '*.sql' | ack 'postgres|sqlite|oracle|mssql' | cut -d/ -f2 | uniq | wc -l 22
so about 10% of our extensions with SQL patches have non-MySQL patchfiles for at least some of their DB changes.
It will be better for everyone if we stop misleading users and clarify what database we support, while empowering more those who want to volunteer to support an alternative DB engine. That would mean:
- update the policy and related pages
- port non-MySQL Database subclasses into external libraries (RfC: Moving database abstractions out of MediaWiki core)
- provide a way to test MediaWiki (and maybe extension) patches with alternative configuration, without forcing the RelEng team to maintain the necessary infrastructure. The ongoing work to make MediaWiki tests run on Travis CI (T75176) provides a possible path for that.