The cons that the author of the post lists make it a no-go. From SQLite not going to work well on sites with multiple authors (a killer from the start) to 'web hosts NEEDING TO ACT RESPONSIBLY' for this to work, literally make this the effort of a OSS project unknown to the WP ecosystem (50% of the web) to force its way into that ecosystem withouth having found any widespread use and people having accommodated it.
If it was worth doing it, someone would have published a plugin for it and it would have been working already. WordPress provides filters for database functions as well. So whatever db you want to use, could be reliably integrated by injecting yourself in between the functions and the db.
Of course, this means that you will immediately face compatibility problems with all the 60,000+ plugins in the ecosystem. And those plugins wont make themselves compatible with SQLite, neither they will accept delirious propositions like 'Make it a requirement for getting accepted to plugin directory'.
People have businesses to run, lives to live. WP ecosystem is not a weekend OSS hobby project for 50% of the web that it runs. People's income, their livelihoods depend on it. Users and developers alike. Nobody will take such arrogance to force them to accommodate some obscure OSS project. Obscure, because you can be sure that 50% of the web that use WordPress have no idea what SQLite is. You, the other ecosystems that you are in and contributing, your professional circle, may have. But the average flower shop owner somewhere in the US and the anime blogger somewhere in Japan, have no freaking idea what SQLite is. And they don't care. They have other things to care about than an OSS project that is unknown to them.
The propositions and the mentality in this thread sound extremely arrogant, and it reminds one about the time when Google tried to force Google+ on the people by forcing them to link their Youtube accounts to Google+. We know how that ended up.
If the OSS project that you love is not gaining traction in a certain demographic, its because it doesn't have use cases there and it does not accommodate those people enough. You cant force people to use it in such a case. You must make it accommodate an actual need and make it easy to use it. Not try to force your way into another ecosystem.
There are those who seem to belong to that community and who seem to literally force themselves. This may be the result of the religious nature of the project as hinted by its religious code of conduct. Just check the different comments in this thread.
I asked you to cite an instance but you declined. An example would be a reasonable basis for discussion. Accusing me of bias doesn't more the debate forward.
If you are unable to see the outrageous comments in this very thread that are so bluntly visible, going to the extremes of calling it to be made a requirement for getting a plugin listed in the repo, then it means that you just dont want to see them. There is no basis for discussion in such a case.
> From SQLite not going to work well on sites with multiple authors (a killer from the start)
This is taken out of context and blown out of proportion. The post says:
"If multiple authors are editing posts on a site and updating them at the same time, then their save requests would run one after the other instead of simultaneously – so there would be a small delay (probably milliseconds, but still a delay)."
So, sure, if your site is so busy that multiple authors are posting within milliseconds of each other, there might be some extremely minor performance issues with SQLite.
See, your question is an excellent example of how little the mainstream tech understands the WP ecosystem:
In any WP site, any user that uses a feature is someone who 'saves content'. They don't need to be an editor. The average user that is commenting on a WP blog, the average customer that is using a WP ecommerce site, the directory user that is bookmarking local lawyers in his area - all of these send write operations to the db. Because all of those features are represented as either custom posts in the database. If a plugin does not use the WP post system, then it still writes to its own tables.
So basically any write action taken in a WP site is very likely a 'post'. Its confusing, so just take the word 'post' as 'data type'. The blog posts in a WordPress site are just data with the type 'post'. WooCommerce products in a WP ecommerce site are just data with the type 'product' and so on.
Therefore, even in a middling WP site with ~1 million unique views/month, you WILL have at least hundreds of users hammering the database with the actions they take.
When you go one level up, things get even more complicated:
There is a WP feature called 'Multisite'. This allows you to provide an infinite amount of WP sites over just one single WP installation by sharing the database and the main files. A lot of big WP sites function like this, including the WordPress.com service that Automattic provides. (50% of all WP sites are there, so 25% of all world's websites).
Which means that in such a Multisite WP installation, there will be at least tens of thousands of site owners, whose blogs, e-stores or sites are serving hundreds of thousands of users at the least. (For smallish WP hosts, nonprofits, communities).
This means that yeah, you will be facing write operations that are much more than 1000 times per second.
...
Regardless, one minor performance situation is not the argument that makes it infeasible to introduce SQLite or any other db engine. The compatibility is king in WP ecosystem - ecosystem-wide and backwards. Just like in any ecosystem that has been able gain and serve a large user base on the Internet.
There wasn't just one con listed in his post at WP org. I just took two of them. There are various others which he honestly lists without realizing that various of them are game-breakers.
> missed sqlite PRAGMAS which would make it behave entirely equal to mysql
More the reason for this being done through a plugin instead of being pushed into WP core. If it provides noticeable improvement and people use it, it will get installed by millions of people. If it does not, it wont.
If it was worth doing it, someone would have published a plugin for it and it would have been working already. WordPress provides filters for database functions as well. So whatever db you want to use, could be reliably integrated by injecting yourself in between the functions and the db.
Of course, this means that you will immediately face compatibility problems with all the 60,000+ plugins in the ecosystem. And those plugins wont make themselves compatible with SQLite, neither they will accept delirious propositions like 'Make it a requirement for getting accepted to plugin directory'.
People have businesses to run, lives to live. WP ecosystem is not a weekend OSS hobby project for 50% of the web that it runs. People's income, their livelihoods depend on it. Users and developers alike. Nobody will take such arrogance to force them to accommodate some obscure OSS project. Obscure, because you can be sure that 50% of the web that use WordPress have no idea what SQLite is. You, the other ecosystems that you are in and contributing, your professional circle, may have. But the average flower shop owner somewhere in the US and the anime blogger somewhere in Japan, have no freaking idea what SQLite is. And they don't care. They have other things to care about than an OSS project that is unknown to them.
The propositions and the mentality in this thread sound extremely arrogant, and it reminds one about the time when Google tried to force Google+ on the people by forcing them to link their Youtube accounts to Google+. We know how that ended up.
If the OSS project that you love is not gaining traction in a certain demographic, its because it doesn't have use cases there and it does not accommodate those people enough. You cant force people to use it in such a case. You must make it accommodate an actual need and make it easy to use it. Not try to force your way into another ecosystem.