It doesn't even currently use real parameterized queries...it has a method that sounds like they are real, but they aren't...just a really hairy bunch of string escaping. They really need to re-write the database layer from scratch.

Behold: https://github.com/WordPress/WordPress/blob/master/wp-includ...

This brings back bad memories. I shouldn’t have reminded myself of what WP code looks like.

> How hard would it be to "add one"/refactor?

From a technical POV: This is potentially straightforward if WordPress leverages (and "blesses", for plug-in developers) a proven abstraction layer like Doctrine DBAL that supports both MySQL and SQLite.

From a non-technical POV: There are tens of thousands of WordPress plug-ins, and even updating the top 1,000 that are good/popular will be a multi-year lift.

plug-ins are likely the real burn.

MediaWiki technically supports PostgreSQL and SQLite for many years, but extensions are really MySQL focused making it the only real choice.

> How hard would it be to "add one"/refactor?

To add one? Trivial.

To refactor all of WP core to use it? I could probably do it in a week or two of focused work.

To enable all plugins and wordpress themes to use it? It is, literally, probably a million times more LOC.

I'd guess very hard. But just refactoring the WordPress codebase isn't enough, you'd ideally want every plugin to adopt the new API as well... Although you could always keep this implementation as the fallback behaviour.

The problem is not adding one. The problem is that it would complicate the infrastructure. From adding more performance requirement to WP wherever it is hosted to the compatibility concerns with plugins. Its a tall tale.

Probably easier to use MySQL as the db layer and have it use SQLite as the backend store somehow heh.