Ari Stathopoulos has posted a report which highlights the different information, implementation, and benefits of SQLite.
According to him, WordPress is used for different kinds of sites, regardless of size or complexity. Further, it also can be used for many purposes. Some of them are:
- Single-page landing sites
- Simple company sites with just a few pages. These sites are usually rarely updated and are essentially static sites with an administration aspect.
- Simple, single-user blogs
- Complex news sites
- e-Commerce sites
- Full-fledged CMS solutions
He also said that WordPress is successful because it is extendable, hookable, and can be used and tweaked to accomplish almost any task on the web.
However, one aspect of WordPress has never changed, regardless of the increase in WP’s use cases and popularity: The database. WordPress requires MySQL/MariaDB to be installed on a site. MySQL is arguably only optimal for some of the scenarios: The “mid-tier” range of site types.
Usually, large sites implement custom database stacks depending on their specific needs.
On the lower end of the series, there are small and simple sites. There are many blogs, company pages, and sites that don’t have many users, posts, etc. These websites don’t always need the complexities of a MySQL/MariaDB database. The requirement of a dedicated MySQL server increases their hosting cost and the complexity of installation. On lower-end servers, it also decreases performance since the same “box” needs to cater to both a PHP and a MySQL/MariaDB server.
The ideal scenario
Ari Stathopoulos, has explained the ideal scenario where he has said that WordPress would allow us to choose the type of database during installation. That could be done using an installation guide, or a simple constant in wp-config.php. To accomplish that, WordPress would need to have a database-abstraction layer. This is not an innovative or radical idea in the CMS space; Drupal has had a solid database-abstraction layer for more than a decade. Laravel, Symfony, and others also include ORMs that allow using multiple database types.
Building a database abstraction layer for WordPress would be a colossal task – though it might be one that, at some point in the future, we may have to undertake to ensure the project’s continued evolution and longevity.
A middle ground
As a middle ground, we could implement a solution for the bottom tier: small to medium sites and blogs. Therefore, these sites don’t need a full-fledged MySQL database necessarily.
SQLite seems to be the perfect fit:
- It is the most widely used database worldwide
- It is cross-platform and can run on any device
- It is included by default on all PHP installations (unless explicitly disabled)
- WordPress’s minimum requirements would be a simple PHP server, without the need for a separate database server.
- SQLite support enables lower hosting costs, decreases energy consumption, and lowers performance costs on lower-end servers.
Implementing SQLite in WordPress Core
It is simple to use SQLite in WordPress at this point. There are some implementations that have been tested thoroughly and proved to work seamlessly. These implementations are drop-in wp-content/db.php files that users can add to their installation which are not hard to use.
However, most people are not aware of these implementation. They might not be aware of the option to buy cheaper hosting sans-mysql. And, then install WordPress using an SQLite database. It is not necessary to know about it. After all, they just want a simple company site or a blog.
WordPress could officially support SQLite by including one of the existing SQLite implementations in Core. So, it is very important to test and support it properly. Additionally, raise the awareness and uncover the option to users.
What would the benefits of SQLite be?
Therefore, Ari Stathopoulos has listed some benefits of supporting officially SQLite. They are:
- Increased performance on lower-end servers and environments.
- Potential for WordPress growth in markets where we did not have access due to the system’s requirements.
- Potential for growth in the hosting market using installation “scenarios”.
- Reduced energy consumption – increased sustainability for the WordPress project.
- Further WordPress’s mission to “democratize publishing” for everyone.
- Easier to contribute to WordPress – download the files and run the built-in PHP server without any other setup required.
- Easier to use automated tests suite.
- Sites can be “portable” and self-contained.
Next steps
He has said that the next step need to be discussed in the comments section of this proposal. If there is consensus to implement SQLite in WordPress Core, an outline of the next steps would look something like this:
- Create the necessary Trac tickets
- Decide how the database type would be defined. The most simple scenario would be a
DATABASE_TYPEconstant inwp-config.php, allowing users to choose if their new site would use a MySQL or SQLite database, but there can be other solutions that come up during a later discussion. - Port an SQLite implementation to WordPress Core, applying the necessary changes like coding standards, in-code documentation, migrate tests, etc.
- Test WordPress Core functionality with SQLite
- Outreach to plugin developers for testing.
The subject of database abstractions and using SQLite was discussed at length during WCEU 2022, in an unofficial capacity, in the hallways. This post is a distilled culmination of these conversations to bring the discussion to the broader community for serious consideration.