Let’s make WordPress officially support SQLite

WordPress can be (and is) used for any kind of site, regardless of size or complexity. Some common use-cases include:

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

Part of the success of WordPress is 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.

Large sites usually implement custom database stacks depending on their specific needs, so are beyond the scope of this proposal.

On the lower end of the spectrum, there are small and simple sites. These are numerous and consist of all the blogs, company pages, and sites that don’t have thousands of users or thousands of 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.

Table of Contents

Toggle

The ideal scenario

Ideally, 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. These sites don’t necessarily need a full-fledged MySQL database.

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

Using SQLite in WordPress is, at this point, simple; There are implementations out there that have been around and evolving for more than 8 years. They have been thoroughly tested and proved to work seamlessly. These implementations are drop-in wp-content/db.php files that users can add to their installation; they are not hard to use.

However, most people are not aware of them. They are not aware that they have the option to buy cheaper hosting sans-mysql and then install WordPress using an SQLite database. Nor should they have 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. We would need to ensure that it is properly tested and supported, and additionally, raise awareness and expose the option to users.

Why should this be in Core and not a plugin?

Picking a database type is something that should happen when a site is first installed. It is not something that should be done after the fact because that would require migrating data from one database to another, which can often be complex.

WordPress includes the MySQL implementation in Core, so if we support SQLite then that implementation should live alongside it.

Data migration can (and should) be in a plugin to facilitate migrations for existing sites should they wish to do that, but the database engine itself belongs in Core.

That will ensure that the implementation is properly supported, properly tested, and WordPress will be able to benefit, as detailed in the following section.

What would the benefits of SQLite be?

Officially supporting SQLite in WordPress could have many benefits. Some notable ones would include:

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

The next steps would 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_TYPE constant in wp-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.

Props @zieladam, @mamaduka, @jonoaldersonwp, @tweetythierry, @SergeyBiryukov, @joostdevalk, @dingo_d, @desmith, @crixu, @williampatton, @costdev, @adamsilverstein, @JavierCasares, @robinwpdeveloper, @aaemnnosttv, @jessibelle for reviewing and contributing to this proposal.